mirror of
https://github.com/postgres/postgres.git
synced 2025-06-05 23:56:58 +03:00
Remove obsoleted README files.
This commit is contained in:
Tom Lane
parent
53ae7acbba
commit
531f58688a
@ -1,8 +1,8 @@
|
|||||||
# $PostgreSQL: pgsql/contrib/spi/Makefile,v 1.27 2007/06/26 22:05:03 tgl Exp $
|
# $PostgreSQL: pgsql/contrib/spi/Makefile,v 1.28 2007/12/03 04:22:54 tgl Exp $
|
||||||
|
|
||||||
MODULES = autoinc insert_username moddatetime refint timetravel
|
MODULES = autoinc insert_username moddatetime refint timetravel
|
||||||
DATA_built = $(addsuffix .sql, $(MODULES))
|
DATA_built = $(addsuffix .sql, $(MODULES))
|
||||||
DOCS = README.spi $(addsuffix .example, $(MODULES))
|
DOCS = $(addsuffix .example, $(MODULES))
|
||||||
|
|
||||||
# this is needed for the regression tests;
|
# this is needed for the regression tests;
|
||||||
# comment out if you want a quieter refint package for other uses
|
# comment out if you want a quieter refint package for other uses
|
||||||
|
|||||||
@ -1,104 +0,0 @@
|
|||||||
|
|
||||||
Here are general trigger functions provided as workable examples
|
|
||||||
of using SPI and triggers. "General" means that functions may be
|
|
||||||
used for defining triggers for any tables but you have to specify
|
|
||||||
table/field names (as described below) while creating a trigger.
|
|
||||||
|
|
||||||
1. refint.c - functions for implementing referential integrity.
|
|
||||||
|
|
||||||
check_primary_key () is to used for foreign keys of a table.
|
|
||||||
|
|
||||||
You are to create trigger (BEFORE INSERT OR UPDATE) using this
|
|
||||||
function on a table referencing another table. You are to specify
|
|
||||||
as function arguments: triggered table column names which correspond
|
|
||||||
to foreign key, referenced table name and column names in referenced
|
|
||||||
table which correspond to primary/unique key.
|
|
||||||
You may create as many triggers as you need - one trigger for
|
|
||||||
one reference.
|
|
||||||
|
|
||||||
check_foreign_key () is to used for primary/unique keys of a table.
|
|
||||||
|
|
||||||
You are to create trigger (BEFORE DELETE OR UPDATE) using this
|
|
||||||
function on a table referenced by another table(s). You are to specify
|
|
||||||
as function arguments: number of references for which function has to
|
|
||||||
performe checking, action if referencing key found ('cascade' - to delete
|
|
||||||
corresponding foreign key, 'restrict' - to abort transaction if foreign keys
|
|
||||||
exist, 'setnull' - to set foreign key referencing primary/unique key
|
|
||||||
being deleted to null), triggered table column names which correspond
|
|
||||||
to primary/unique key, referencing table name and column names corresponding
|
|
||||||
to foreign key (, ... - as many referencing tables/keys as specified
|
|
||||||
by first argument).
|
|
||||||
Note, that NOT NULL constraint and unique index have to be defined by
|
|
||||||
youself.
|
|
||||||
|
|
||||||
There are examples in refint.example and regression tests
|
|
||||||
(sql/triggers.sql).
|
|
||||||
|
|
||||||
To CREATE FUNCTIONs use refint.sql (will be made by gmake from
|
|
||||||
refint.source).
|
|
||||||
|
|
||||||
|
|
||||||
2. timetravel.c - functions for implementing time travel feature.
|
|
||||||
|
|
||||||
Old internally supported time-travel (TT) used insert/delete
|
|
||||||
transaction commit times. To get the same feature using triggers
|
|
||||||
you are to add to a table two columns of abstime type to store
|
|
||||||
date when a tuple was inserted (start_date) and changed/deleted
|
|
||||||
(stop_date):
|
|
||||||
|
|
||||||
CREATE TABLE XXX (
|
|
||||||
... ...
|
|
||||||
date_on abstime default currabstime(),
|
|
||||||
date_off abstime default 'infinity'
|
|
||||||
... ...
|
|
||||||
);
|
|
||||||
|
|
||||||
- so, tuples being inserted with NULLs in date_on/date_off will get
|
|
||||||
_current_date_ in date_on (name of start_date column in XXX) and INFINITY in
|
|
||||||
date_off (name of stop_date column in XXX).
|
|
||||||
|
|
||||||
Tuples with stop_date equal INFINITY are "valid now": when trigger will
|
|
||||||
be fired for UPDATE/DELETE of a tuple with stop_date NOT equal INFINITY then
|
|
||||||
this tuple will not be changed/deleted!
|
|
||||||
|
|
||||||
If stop_date equal INFINITY then on
|
|
||||||
|
|
||||||
UPDATE: only stop_date in tuple being updated will be changed to current
|
|
||||||
date and new tuple with new data (coming from SET ... in UPDATE) will be
|
|
||||||
inserted. Start_date in this new tuple will be setted to current date and
|
|
||||||
stop_date - to INFINITY.
|
|
||||||
|
|
||||||
DELETE: new tuple will be inserted with stop_date setted to current date
|
|
||||||
(and with the same data in other columns as in tuple being deleted).
|
|
||||||
|
|
||||||
NOTE:
|
|
||||||
1. To get tuples "valid now" you are to add _stop_date_ = 'infinity'
|
|
||||||
to WHERE. Internally supported TT allowed to avoid this...
|
|
||||||
Fixed rewriting RULEs could help here...
|
|
||||||
As work arround you may use VIEWs...
|
|
||||||
2. You can't change start/stop date columns with UPDATE!
|
|
||||||
Use set_timetravel (below) if you need in this.
|
|
||||||
|
|
||||||
FUNCTIONs:
|
|
||||||
|
|
||||||
timetravel() is general trigger function.
|
|
||||||
|
|
||||||
You are to create trigger BEFORE (!!!) UPDATE OR DELETE using this
|
|
||||||
function on a time-traveled table. You are to specify two arguments: name of
|
|
||||||
start_date column and name of stop_date column in triggered table.
|
|
||||||
|
|
||||||
currabstime() may be used in DEFAULT for start_date column to get
|
|
||||||
current date.
|
|
||||||
|
|
||||||
set_timetravel() allows you turn time-travel ON/OFF for a table:
|
|
||||||
|
|
||||||
set_timetravel('XXX', 1) will turn TT ON for table XXX (and report
|
|
||||||
old status).
|
|
||||||
set_timetravel('XXX', 0) will turn TT OFF for table XXX (-"-).
|
|
||||||
|
|
||||||
Turning TT OFF allows you do with a table ALL what you want.
|
|
||||||
|
|
||||||
There is example in timetravel.example.
|
|
||||||
|
|
||||||
To CREATE FUNCTIONs use timetravel.sql (will be made by gmake from
|
|
||||||
timetravel.source).
|
|
||||||
@ -1,116 +0,0 @@
|
|||||||
2. timetravel.c - functions for implementing time travel feature.
|
|
||||||
|
|
||||||
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
|
|
||||||
I rewritten this, because:
|
|
||||||
|
|
||||||
on original version of postgresql 7.3.2-7.3.3:
|
|
||||||
|
|
||||||
the UPDATE not work on timetravel.example if I added
|
|
||||||
>create unique index tttest_idx on tttest (price_id,price_off);
|
|
||||||
>update tttest set price_val = 30 where price_id = 3;
|
|
||||||
ERROR: Cannot insert a duplicate key into unique index tttest_idx
|
|
||||||
|
|
||||||
And UPDATE not work on table tttest after
|
|
||||||
>alter table tttest add column q1 text;
|
|
||||||
>alter table tttest add column q2 int;
|
|
||||||
>alter table tttest drop column q1;
|
|
||||||
>update tttest set price_val = 30 where price_id = 3;
|
|
||||||
ERROR: Parameter '$5' is out of range
|
|
||||||
|
|
||||||
And I add a new optional feature: my new timetravel have +3 optional parameters:
|
|
||||||
inserter_user, updater_user, deleter_user.
|
|
||||||
|
|
||||||
And I add a new function: get_timetravel for get timetravel status
|
|
||||||
without change it.
|
|
||||||
|
|
||||||
A big difference:
|
|
||||||
the old version on UPDATE changed oid on active ('infinity') record,
|
|
||||||
the new version UPDATE keep oid, and the overdued record have a new oid.
|
|
||||||
I sign with '!!!' my comment in this file.
|
|
||||||
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
|
|
||||||
|
|
||||||
Old internally supported time-travel (TT) used insert/delete
|
|
||||||
transaction commit times. To get the same feature using triggers
|
|
||||||
you are to add to a table two columns of abstime type to store
|
|
||||||
date when a tuple was inserted (start_date) and changed/deleted
|
|
||||||
(stop_date):
|
|
||||||
|
|
||||||
CREATE TABLE XXX (
|
|
||||||
... ...
|
|
||||||
date_on abstime default currabstime(),
|
|
||||||
date_off abstime default 'infinity'
|
|
||||||
... ...
|
|
||||||
/* !!! and (if have) */
|
|
||||||
ins_user text /* user, who insert this record */
|
|
||||||
upd_user text /* user, who updated this record */
|
|
||||||
del_user text /* user, who deleted this record */
|
|
||||||
... ...
|
|
||||||
);
|
|
||||||
|
|
||||||
!!! on INSERT my new version:
|
|
||||||
... and optionally set ins_user to current user, upd_user and del_user to null.
|
|
||||||
|
|
||||||
- so, tuples being inserted with NULLs in date_on/date_off will get
|
|
||||||
_current_date_ in date_on (name of start_date column in XXX) and INFINITY in
|
|
||||||
date_off (name of stop_date column in XXX).
|
|
||||||
|
|
||||||
Tuples with stop_date equal INFINITY are "valid now": when trigger will
|
|
||||||
be fired for UPDATE/DELETE of a tuple with stop_date NOT equal INFINITY then
|
|
||||||
this tuple will not be changed/deleted!
|
|
||||||
|
|
||||||
If stop_date equal INFINITY then on
|
|
||||||
|
|
||||||
UPDATE:
|
|
||||||
original version was:
|
|
||||||
only stop_date in tuple being updated will be changed to current
|
|
||||||
date and new tuple with new data (coming from SET ... in UPDATE) will be
|
|
||||||
inserted. Start_date in this new tuple will be setted to current date and
|
|
||||||
stop_date - to INFINITY.
|
|
||||||
On my new version:
|
|
||||||
insert a new tuple with old values, but stop_date changed to current date;
|
|
||||||
and update original tuple with new data, and update start_date to current date
|
|
||||||
and optionally set upd_user to current user and clear ins_user,del_user.
|
|
||||||
|
|
||||||
DELETE: new tuple will be inserted with stop_date setted to current date
|
|
||||||
(and with the same data in other columns as in tuple being deleted).
|
|
||||||
On my new version:
|
|
||||||
... and optionally set del_user to current user.
|
|
||||||
|
|
||||||
NOTE:
|
|
||||||
1. To get tuples "valid now" you are to add _stop_date_ = 'infinity'
|
|
||||||
to WHERE. Internally supported TT allowed to avoid this...
|
|
||||||
Fixed rewriting RULEs could help here...
|
|
||||||
As work arround you may use VIEWs...
|
|
||||||
2. You can't change start/stop date columns with UPDATE!
|
|
||||||
Use set_timetravel (below) if you need in this.
|
|
||||||
|
|
||||||
FUNCTIONs:
|
|
||||||
|
|
||||||
timetravel() is general trigger function.
|
|
||||||
|
|
||||||
You are to create trigger BEFORE UPDATE OR DELETE using this
|
|
||||||
function on a time-traveled table. You are to specify two arguments: name of
|
|
||||||
start_date column and name of stop_date column in triggered table.
|
|
||||||
Or add +3 arguments:
|
|
||||||
name of insert_user column, name of update_user column, name of delete_user column
|
|
||||||
|
|
||||||
currabstime() may be used in DEFAULT for start_date column to get
|
|
||||||
current date.
|
|
||||||
!!! I deleted this function, because I newer used this.
|
|
||||||
|
|
||||||
set_timetravel() allows you turn time-travel ON/OFF for a table:
|
|
||||||
|
|
||||||
set_timetravel('XXX', 1) will turn TT ON for table XXX (and report
|
|
||||||
old status).
|
|
||||||
set_timetravel('XXX', 0) will turn TT OFF for table XXX (-"-).
|
|
||||||
|
|
||||||
Turning TT OFF allows you do with a table ALL what you want.
|
|
||||||
|
|
||||||
get_timetravel() reports time-travel status ON(1)/OFF(0) for a table.
|
|
||||||
get_timetravel() and set_timetravel() not checking existing of table and
|
|
||||||
existing of timetravel trigger on specified table.
|
|
||||||
|
|
||||||
There is example in timetravel.example.
|
|
||||||
|
|
||||||
To CREATE FUNCTIONs use timetravel.sql (will be made by gmake from
|
|
||||||
timetravel.source).
|
|
||||||
@ -1,10 +1,9 @@
|
|||||||
# $PostgreSQL: pgsql/contrib/test_parser/Makefile,v 1.1 2007/10/15 21:36:50 tgl Exp $
|
# $PostgreSQL: pgsql/contrib/test_parser/Makefile,v 1.2 2007/12/03 04:22:54 tgl Exp $
|
||||||
|
|
||||||
MODULE_big = test_parser
|
MODULE_big = test_parser
|
||||||
OBJS = test_parser.o
|
OBJS = test_parser.o
|
||||||
DATA_built = test_parser.sql
|
DATA_built = test_parser.sql
|
||||||
DATA = uninstall_test_parser.sql
|
DATA = uninstall_test_parser.sql
|
||||||
DOCS = README.test_parser
|
|
||||||
REGRESS = test_parser
|
REGRESS = test_parser
|
||||||
|
|
||||||
ifdef USE_PGXS
|
ifdef USE_PGXS
|
||||||
|
|||||||
@ -1,52 +0,0 @@
|
|||||||
Example parser
|
|
||||||
==============
|
|
||||||
|
|
||||||
This is an example of a custom parser for full text search.
|
|
||||||
|
|
||||||
It recognizes space-delimited words and returns only two token types:
|
|
||||||
|
|
||||||
- 3, word, Word
|
|
||||||
|
|
||||||
- 12, blank, Space symbols
|
|
||||||
|
|
||||||
The token numbers have been chosen to keep compatibility with the default
|
|
||||||
ts_headline() function, since we do not want to implement our own version.
|
|
||||||
|
|
||||||
* Configuration
|
|
||||||
|
|
||||||
The parser has no user-configurable parameters.
|
|
||||||
|
|
||||||
* Usage
|
|
||||||
|
|
||||||
1. Compile and install
|
|
||||||
|
|
||||||
2. Load dictionary
|
|
||||||
|
|
||||||
psql mydb < test_parser.sql
|
|
||||||
|
|
||||||
3. Test it
|
|
||||||
|
|
||||||
mydb# SELECT * FROM ts_parse('testparser','That''s my first own parser');
|
|
||||||
tokid | token
|
|
||||||
-------+--------
|
|
||||||
3 | That's
|
|
||||||
12 |
|
|
||||||
3 | my
|
|
||||||
12 |
|
|
||||||
3 | first
|
|
||||||
12 |
|
|
||||||
3 | own
|
|
||||||
12 |
|
|
||||||
3 | parser
|
|
||||||
|
|
||||||
mydb# SELECT to_tsvector('testcfg','That''s my first own parser');
|
|
||||||
to_tsvector
|
|
||||||
-------------------------------------------------
|
|
||||||
'my':2 'own':4 'first':3 'parser':5 'that''s':1
|
|
||||||
|
|
||||||
mydb# SELECT ts_headline('testcfg','Supernovae stars are the brightest phenomena in galaxies', to_tsquery('testcfg', 'star'));
|
|
||||||
headline
|
|
||||||
-----------------------------------------------------------------
|
|
||||||
Supernovae <b>stars</b> are the brightest phenomena in galaxies
|
|
||||||
|
|
||||||
That's all.
|
|
||||||
Loading…
x
Reference in New Issue
Block a user