From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: array support patch phase 1 patch |
Date: | 2003-04-08 19:47:03 |
Message-ID: | 1049831223.1874.8.camel@fuji.krosing.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Joe Conway kirjutas T, 08.04.2003 kell 19:55:
> Hannu Krosing wrote:
> > SELECT ARRAY[1,2] < ARRAY[1,2,3]; # --> FALSE
> >
> > Support for sorting and b-tree indexing could be nice too.
>
> I thought briefly about this, but it wasn't immediately clear what the
> semantics ought to be in all cases. I've also spent literally all my
> available "hacking" time for the last several weeks just to get to the
> patch submitted. I'd like to see at least some of it committed before I
> take on anything new ;-)
>
> If you want to propose in detail how these would behave - including:
I like the "compare like strings" approach
> - different length arrays
shorter is smaller if all elements are same
> - different dimension arrays
not comparable, just as array elemant is not comparable with array
> - is comparison by ordinal position, or is each element compared to
> all elements of the other side,
neither, pairs of elements at same positions are compared until first !=
or one array ends, then the shorter array the array with smaller element
value is considered smaller.
> e.g. is
> (ARRAY[1,2,3] < ARRAY[2,3,4]) TRUE or FALSE?
> If you compare by ordinal position TRUE, but in the latter case
> FALSE
all the following should also be TRUE
(ARRAY[1,2,3] < ARRAY[2,1,1])
(ARRAY[1,2,3] < ARRAY[1,2,3,4])
(ARRAY[] < ARRAY[1,2,3,4])
(ARRAY[1,2,3,4] < ARRAY[1,2,4,3])
> > Where should one start to add PL/Python support for polymorphic types ?
>
> Not entirely sure. In plperl, pltcl, and plr there is a section of code
> in the compile function that looks something like:
>
> ....
Thanks, I'll take a look.
> > What about moving contrib/intagg into backend ?
> > (And converting it into ANYagg on the way ;)
> >
>
> As I said earlier, all in good time ;-) One question about that though
> -- how is intagg different from array_accum? (which is already
> polymorphic and in the submitted patch)
Sorry, didn't notice array_accum.
intagg has functions for doing it both ways (array->table and table ->
array).
-----------------
Hannu
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2003-04-09 02:30:39 | Minor doc patch for charset |
Previous Message | Joe Conway | 2003-04-08 16:55:51 | Re: array support patch phase 1 patch |