Message-Id: <9302091956.AA20179@postgres.Berkeley.EDU>
From: aoki@postgres.Berkeley.EDU
Subject: Re: check an element in a variable-length array.
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
In-Reply-To: Your message of Tue, 09 Feb 93 12:44:17 -0800 
	     <9302090442.AA15052@postgres.Berkeley.EDU> 
Date: Tue, 09 Feb 93 11:56:25 -0800
From: aoki@postgres.Berkeley.EDU

> Is there any way to check if an elment is in a variable-length array?

this is my read on arrays, which is based on my read of the code.
i might have missed something.  someone flame me if i did.

arrays are not like a container class; they are implemented as ADTs,
with catalog entries on a per-contained-type basis.  this means that 
all non-built-in operations on arrays (see below) have to be implemented 
as user-defined functions.  unfortunately, these functions will be
specific to the contained type.  that is, if you want a query-language 
interface to int4 arrays, you have to implement functions like

	add_element_to_int4_array
	int4_array_inclusion_test
	remove_element_from_int4_array
	...

(i made these names up, the names aren't important) and then make the 
appropriate function and operator catalog entries.  (e.g., perhaps you
want to make "+" the add-element operator for int4 arrays).  this process 
must be duplicated for each contained type.  it would be nice to be able 
to have a polymorphic set of these routines, but the common array 
structure is not self-describing.

array creation (e.g., ``foo = "{a, b, c}"'') and reference into arrays
(e.g., ``foo = a[5]'') are handled through a sort of fake polymorphism --
the parser can determine the array type from the query expression, and 
special-case code is used to make sure the appropriate functions are
informed of the id of the contained type.  this mechanism currently does 
not generalize to any other operations on array types; this, combined with 
the fact that the arrays are not self-describing, leads to the lots-of-
functions-per-type problem in the last paragraph.

anyway, the upshot is that ANY operation on arrays except:
	input of an entire array attribute
	output of an entire array attribute
	reading a single array element
	replacing an entire array attribute
will require some coding and catalog-munging.

note that the implementation of arrays as ADTs places the same limits on
their size as are documented for non-large-objects (gak!  what a phrase)
in general.

oh, yeah.  there is no notion of iterator variables.
--
  Paul M. Aoki  |  CS Div., Dept. of EECS, UCB  |  aoki@postgres.Berkeley.EDU
                |  Berkeley, CA 94720           |  ...!uunet!ucbvax!aoki

  TO REMOVE YOURSELF FROM THE POSTGRES MAILING LIST: SEND MAIL TO
		  postgres-request@postgres.berkeley.edu
  WITH A SUBJECT LINE OF "DEL".  DO NOT SEND MAIL TO THE POSTGRES LIST!