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

Re: array support patch phase 1 patch

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: (view raw, whole thread or download thread mbox)
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 ->


In response to

pgsql-patches by date

Next:From: Christopher Kings-LynneDate: 2003-04-09 02:30:39
Subject: Minor doc patch for charset
Previous:From: Joe ConwayDate: 2003-04-08 16:55:51
Subject: Re: array support patch phase 1 patch

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