Skip to content
Snippets Groups Projects
Commit 531f5868 authored by Tom Lane's avatar Tom Lane
Browse files

Remove obsoleted README files.

parent 53ae7acb
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
contrib/spi/Makefile
+ 2
− 2
View file @ 531f5868
# $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
......
contrib/spi/README.spi deleted 100644 → 0
+ 0
− 104
View file @ 53ae7acb
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).
contrib/spi/README.timetravel deleted 100644 → 0
+ 0
− 116
View file @ 53ae7acb
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).
contrib/test_parser/Makefile
+ 1
− 2
View file @ 531f5868
# $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
......
contrib/test_parser/README.test_parser deleted 100644 → 0
+ 0
− 52
View file @ 53ae7acb
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.
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment