Remove old doc files, now README.
This commit is contained in:
parent
5683e704d0
commit
fca9295fab
@ -1,49 +0,0 @@
|
||||
Array iterator functions, by Massimo Dal Zotto <dz@cs.unitn.it>
|
||||
Copyright (C) 1999, Massimo Dal Zotto <dz@cs.unitn.it>
|
||||
|
||||
This software is distributed under the GNU General Public License
|
||||
either version 2, or (at your option) any later version.
|
||||
|
||||
|
||||
This loadable module defines a new class of functions which take
|
||||
an array and a scalar value, iterate a scalar operator over the
|
||||
elements of the array and the value, and compute a result as
|
||||
the logical OR or AND of the iteration results.
|
||||
For example array_int4eq returns true if some of the elements
|
||||
of an array of int4 is equal to the given value:
|
||||
|
||||
array_int4eq({1,2,3}, 1) --> true
|
||||
array_int4eq({1,2,3}, 4) --> false
|
||||
|
||||
If we have defined T array types and O scalar operators we can
|
||||
define T x O x 2 array functions, each of them has a name like
|
||||
"array_[all_]<basetype><operation>" and takes an array of type T
|
||||
iterating the operator O over all the elements. Note however
|
||||
that some of the possible combination are invalid, for example
|
||||
the array_int4_like because there is no like operator for int4.
|
||||
|
||||
We can then define new operators based on these functions and use
|
||||
them to write queries with qualification clauses based on the
|
||||
values of some of the elements of an array.
|
||||
For example to select rows having some or all element of an array
|
||||
attribute equal to a given value or matching a regular expression:
|
||||
|
||||
create table t(id int4[], txt text[]);
|
||||
|
||||
-- select tuples with some id element equal to 123
|
||||
select * from t where t.id *= 123;
|
||||
|
||||
-- select tuples with some txt element matching '[a-z]'
|
||||
select * from t where t.txt *~ '[a-z]';
|
||||
|
||||
-- select tuples with all txt elements matching '^[A-Z]'
|
||||
select * from t where t.txt[1:3] **~ '^[A-Z]';
|
||||
|
||||
The scheme is quite general, each operator which operates on a base type
|
||||
can be iterated over the elements of an array. It seem to work well but
|
||||
defining each new operators requires writing a different C function.
|
||||
Furthermore in each function there are two hardcoded OIDs which reference
|
||||
a base type and a procedure. Not very portable. Can anyone suggest a
|
||||
better and more portable way to do it ?
|
||||
|
||||
See also array_iterator.sql for an example on how to use this module.
|
@ -1,43 +0,0 @@
|
||||
Miscellaneous utility functions for PostgreSQL.
|
||||
Copyright (C) 1999, Massimo Dal Zotto <dz@cs.unitn.it>
|
||||
|
||||
This software is distributed under the GNU General Public License
|
||||
either version 2, or (at your option) any later version.
|
||||
|
||||
query_limit(n)
|
||||
|
||||
sets a limit on the maximum numbers of query returned from
|
||||
a backend. It can be used to limit the result size retrieved
|
||||
by the application for poor input data or to avoid accidental
|
||||
table product while playying with sql.
|
||||
|
||||
backend_pid()
|
||||
|
||||
return the pid of our corresponding backend.
|
||||
|
||||
unlisten(relname)
|
||||
|
||||
unlisten from a relation or from all relations if the argument
|
||||
is null, empty or '*'.
|
||||
It is now obsoleted by the new unlisten command but still useful
|
||||
if you want unlisten a name computed by the query.
|
||||
Note that a listen/notify relname can be any ascii string, not
|
||||
just valid relation names.
|
||||
|
||||
min(x,y)
|
||||
max(x,y)
|
||||
|
||||
return the min or max bteween two integers.
|
||||
|
||||
assert_enable(bool)
|
||||
|
||||
enable/disable assert checkings in the backend, if it has been
|
||||
compiled with USE_ASSERT_CHECKING.
|
||||
|
||||
assert_test(bool)
|
||||
|
||||
test the assert enable/disable code, if the backend has been
|
||||
compiled with ASSERT_CHECKING_TEST.
|
||||
|
||||
--
|
||||
Massimo Dal Zotto <dz@cs.unitn.it>
|
@ -1,23 +0,0 @@
|
||||
String io module for postgresql.
|
||||
Copyright (C) 1999, Massimo Dal Zotto <dz@cs.unitn.it>
|
||||
|
||||
This software is distributed under the GNU General Public License
|
||||
either version 2, or (at your option) any later version.
|
||||
|
||||
|
||||
These output functions can be used as substitution of the standard text
|
||||
output functions to get the value of text fields printed in the format
|
||||
used for C strings. This allows the output of queries or the exported
|
||||
files to be processed more easily using standard unix filter programs
|
||||
like perl or awk.
|
||||
|
||||
If you use the standard functions instead you could find a single tuple
|
||||
splitted into many lines and the tabs embedded in the values could be
|
||||
confused with those used as field delimters.
|
||||
|
||||
My function translates all non-printing characters into corresponding
|
||||
esacape sequences as defined by the C syntax. All you need to reconstruct
|
||||
the exact value in your application is a corresponding unescape function
|
||||
like the string_input defined in the source code.
|
||||
|
||||
Massimo Dal Zotto <dz@cs.unitn.it>
|
@ -1,55 +0,0 @@
|
||||
User locks, by Massimo Dal Zotto <dz@cs.unitn.it>
|
||||
Copyright (C) 1999, Massimo Dal Zotto <dz@cs.unitn.it>
|
||||
|
||||
This software is distributed under the GNU General Public License
|
||||
either version 2, or (at your option) any later version.
|
||||
|
||||
|
||||
This loadable module, together with my user-lock.patch applied to the
|
||||
backend, provides support for user-level long-term cooperative locks.
|
||||
For example one can write:
|
||||
|
||||
select some_fields, user_write_lock_oid(oid) from table where id='key';
|
||||
|
||||
Now if the returned user_write_lock_oid field is 1 you have acquired an
|
||||
user lock on the oid of the selected tuple and can now do some long operation
|
||||
on it, like let the data being edited by the user.
|
||||
If it is 0 it means that the lock has been already acquired by some other
|
||||
process and you should not use that item until the other has finished.
|
||||
Note that in this case the query returns 0 immediately without waiting on
|
||||
the lock. This is good if the lock is held for long time.
|
||||
After you have finished your work on that item you can do:
|
||||
|
||||
update table set some_fields where id='key';
|
||||
select user_write_unlock_oid(oid) from table where id='key';
|
||||
|
||||
You can also ignore the failure and go ahead but this could produce conflicts
|
||||
or inconsistent data in your application. User locks require a cooperative
|
||||
behavior between users. User locks don't interfere with the normal locks
|
||||
used by postgres for transaction processing.
|
||||
|
||||
This could also be done by setting a flag in the record itself but in
|
||||
this case you have the overhead of the updates to the records and there
|
||||
could be some locks not released if the backend or the application crashes
|
||||
before resetting the lock flag.
|
||||
It could also be done with a begin/end block but in this case the entire
|
||||
table would be locked by postgres and it is not acceptable to do this for
|
||||
a long period because other transactions would block completely.
|
||||
|
||||
The generic user locks use two values, group and id, to identify a lock,
|
||||
which correspond to ip_posid and ip_blkid of an ItemPointerData.
|
||||
Group is a 16 bit value while id is a 32 bit integer which could also be
|
||||
an oid. The oid user lock functions, which take only an oid as argument,
|
||||
use a group equal to 0.
|
||||
|
||||
The meaning of group and id is defined by the application. The user
|
||||
lock code just takes two numbers and tells you if the corresponding
|
||||
entity has been succesfully locked. What this mean is up to you.
|
||||
|
||||
My succestion is that you use the group to identify an area of your
|
||||
application and the id to identify an object in this area.
|
||||
Or you can just lock the oid of the tuples which are by definition unique.
|
||||
|
||||
Note also that a process can acquire more than one lock on the same entity
|
||||
and it must release the lock the corresponding number of times. This can
|
||||
be done calling the unlock funtion until it returns 0.
|
Loading…
Reference in New Issue
Block a user