mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-22 03:43:22 +02:00
* Add option to build with OpenSSL out of the box. Fix thusly exposed bit rot. Although it compiles now, getting this to do something useful is left as an exercise. * Fix Kerberos options to defer checking for required libraries until all the other libraries are checked for. * Change default odbcinst.ini and krb5.srvtab path to PREFIX/etc. * Install work around for Autoconf's install-sh relative path anomaly. Get rid of old INSTL_*_OPTS variables, now that we don't need them anymore. * Use `gunzip -c' instead of g?zcat. Reportedly broke on AIX. * Look for only one of readline.h or readline/readline.h, not both. * Make check for PS_STRINGS cacheable. Don't test for the header files separately. * Disable fcntl(F_SETLK) test on Linux. * Substitute the standard GCC warnings set into CFLAGS in configure, don't add it on in Makefile.global. * Sweep through contrib tree to teach makefiles standard semantics. ... and in completely unrelated news: * Make postmaster.opts arbitrary options-aware. I still think we need to save the environment as well. |
||
---|---|---|
.. | ||
array_iterator.c | ||
array_iterator.h | ||
array_iterator.sql.in | ||
Makefile | ||
README.array_iterator |
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.