postgresql

History

Tom Lane f45df8c014 Cause CHAR(n) to TEXT or VARCHAR conversion to automatically strip trailing blanks, in hopes of reducing the surprise factor for newbies. Remove redundant operators for VARCHAR (it depends wholly on TEXT operations now). Clean up resolution of ambiguous operators/functions to avoid surprising choices for domains: domains are treated as equivalent to their base types and binary-coercibility is no longer considered a preference item when choosing among multiple operators/functions. IsBinaryCoercible now correctly reflects the notion that you need only relabel the type to get from type A to type B: that is, a domain is binary-coercible to its base type, but not vice versa. Various marginal cleanup, including merging the essentially duplicate resolution code in parse_func.c and parse_oper.c. Improve opr_sanity regression test to understand about binary compatibility (using pg_cast), and fix a couple of small errors in the catalogs revealed thereby. Restructure "special operator" handling to fetch operators via index opclasses rather than hardwiring assumptions about names (cleans up the pattern_ops stuff a little).		2003-05-26 00:11:29 +00:00
..
Makefile	To fix the perpetually broken makefiles in the contrib tree, I have	2001-09-06 10:49:30 +00:00
README.array_iterator	Modify array operations to include array's element type OID in the	2002-08-26 17:54:02 +00:00
array_iterator.c	Cause CHAR(n) to TEXT or VARCHAR conversion to automatically strip trailing	2003-05-26 00:11:29 +00:00
array_iterator.h	Cause CHAR(n) to TEXT or VARCHAR conversion to automatically strip trailing	2003-05-26 00:11:29 +00:00
array_iterator.sql.in	Cause CHAR(n) to TEXT or VARCHAR conversion to automatically strip trailing	2003-05-26 00:11:29 +00:00

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 operator requires writing a different C function.
This is tedious, and error-prone since one must take care that the correct
datatypes are associated with the selected underlying function.
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.