Subject: Arrays

From: [email-masked]
Date: Tue, 28 Jul 92 12:45:29 -0700

I've been thinking about arrays in Postgres, and the more that I've
thought about them the more they've bothered me, until I decided to
share my thoughts with you all.

Mathematically, an array is just a special kind of relation.  If
Postgres treated them in this general way (despite their being
implemented specially), there would be no question about how
to update specific elements, etc.  But then, what about the special
square bracket syntax for arrays?  It could be viewed as syntactic
sugar that was applicable to any relation of the appropriate form.

In more detail, I'm suggesting that relation[index] should apply to
any relation (including, but not limited to, special array relations)
which has only two fields.  Index would select on the first column and
the matching value in the second column would be returned.  It would
be an error if there were two matches, since arrays are functions.

This can be generalized to n-dimensional arrays by allowing
var.field[index_1,...,index_n] to select values from the (n+1)st (and
last) column of a relation given the values of fields 1-n.

Further generalizations are possible but the main advantage I see is
conceptually getting rid of arrays as special kinds of animals
demanding new features with each release.

Does this seem like a good idea?

_Greg

J. Greg Davidson	Institute for Software Research and Development
+1 (619) 452-8059       6231 Branting Street  San Diego, CA  92122  USA
 
[email-masked]					ucsd----+--vis
[email-masked]		 			nosc----|

	*****************************************************
	*   Member of the League for Programming Freedom.   *
	*   For more info, write to [email-masked]  *
	*****************************************************

---

From: <[email-masked]>
Date: Wed, 29 Jul 92 15:18:32 PDT

> be an error if there were two matches, since arrays are functions.

this is a very interesting idea.  here are some problems i can see:

    +  the additional overhead of maintaining a class for every array
       of ten ascii characters is prohibitive.

    +  storing a tuple per element is pretty inefficient.  tuple
       headers in postgres are 64 bytes, so your elements have to
       be pretty big (or your array pretty sparse) before overhead
       stops killing you.

    +  there's an implicit assumption that the keys of the array
       elements is in some way descriptive of their ordering.  this
       doesn't lead to incorrect behavior, but may, for example,
       lead to poor performance if logically adjacent entries in an
       array are wildly distant from one another physically.

i'll bring this up at the next postgres group meeting to see if anyone
else has reactions.  if nothing else, this may be a sensible way to
provide support for sparse arrays of scientific data.  thanks for
sending your ideas along.
					mike olson
					project sequoia 2000
					uc berkeley
					[email-masked]