Skip site navigation (1) Skip section navigation (2)

Re: array support patch phase 1 patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Joe Conway <mail(at)joeconway(dot)com>,"Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: array support patch phase 1 patch
Date: 2003-04-08 14:01:37
Message-ID: 26491.1049810497@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Joe Conway writes:
>> ...etc up to 6 dimensions

> Why only 6?

See uses of MAXDIM.  If you feel that 6 isn't enough, I wouldn't have
a problem with raising MAXDIM to 10 or so.  I don't think it's worth
trying to eliminate the limit completely; that would add palloc overhead
to every array operation, for a feature people are unlikely to use.

>> 4. Duplicated contrib/array functionality (and then some) in the
>> backend using polymorphic functions and operators.

> Couldn't this kind of operation be handled more cleanly (at least
> semantically speaking), if we provide a function that converts an array to
> a set and then use standard set searching operations?  For example,
> SELECT 2 IN TABLE(ARRAY[1,2,3]);

Not sure about that.  Is there any guidance in the SQL 200x spec about
what they expect people to actually *do* with the ARRAY[] syntax?

I'm currently working over the patch, but am not going to commit this
part (yet), since I have some problems with the implementation anyway.

>> 5. Side note: I added ANYARRAY1 and ANYELEMENT1 in this version.

> Doing what?

I'm hoping to avoid committing those, as they don't seem to be
completely implemented in this patch.  They may be required to
represent the behavior of array_coerce() though.  Not sure yet.

			regards, tom lane


In response to

pgsql-patches by date

Next:From: Joe ConwayDate: 2003-04-08 16:19:13
Subject: Re: array support patch phase 1 patch
Previous:From: Hannu KrosingDate: 2003-04-08 13:55:44
Subject: Re: array support patch phase 1 patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group