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

Re: array support patch phase 1 patch

From: Joe Conway <mail(at)joeconway(dot)com>
To: Hannu Krosing <hannu(at)tm(dot)ee>
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 16:55:51
Message-ID: 3E92FF17.7020300@joeconway.com (view raw or flat)
Thread:
Lists: pgsql-patches
Hannu Krosing wrote:
> How hard would it be to add
> 
> array_eq, array_ne, array_gt, array_le and corresponding operators
> 
> SELECT ARRAY[1,2,3] = ARRAY[1,2,3];  # --> TRUE
> SELECT ARRAY[1,2,3] < ARRAY[1,2,3];  # --> FALSE
> SELECT ARRAY[1,2,3] <= ARRAY[1,2,3];  # --> TRUE
> SELECT ARRAY[1,2,3] > ARRAY[1,2,3];  # --> FALSE
> SELECT ARRAY[1,2,3] >= ARRAY[1,2,3];  # --> TRUE
> 
> I'd assume them to behave like string comparisons, i.e shorter subarray
> is smaller:
> 
> 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:
   - different length arrays
   - different dimension arrays
   - is comparison by ordinal position, or is each element compared to
     all elements of the other side, 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

> 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:

/* Disallow pseudotype result, except VOID */
if (typeStruct->typtype == 'p')
{
     if (procStruct->prorettype == VOIDOID)
       /* okay */ ;
     else if (procStruct->prorettype == TRIGGEROID)
     {
       free(prodesc->proname);
       free(prodesc);
       elog(ERROR, "plperl functions cannot return type %s"
		 "\n\texcept when used as triggers",
                  format_type_be(procStruct->prorettype));

And something similar for arguments. But I don't at quick glance see 
something like this in plpython.

This needs to be changed to allow types ANYARRAYOID and ANYELEMENTOID. 
Then you need to do the right thing with the arguments/return type. For 
example, from plr:

#define GET_PROARGS(pronargs_, proargtypes_) \
do { \
   int i; \
   pronargs_ = procStruct->pronargs; \
   for (i = 0; i < pronargs_; i++) \
   { \
     if (procStruct->proargtypes[i] == ANYARRAYOID || \
       procStruct->proargtypes[i] == ANYELEMENTOID) \
       { \
         proargtypes_[i] = get_expr_argtype(fcinfo, i); \
         if (proargtypes_[i] == InvalidOid) \
           proargtypes_[i] = procStruct->proargtypes[i]; \
       } \
       else \
         proargtypes_[i] = procStruct->proargtypes[i]; \
       } \
} while (0)

This grabs the parser determined runtime datatype from the expression 
node that has been added to FmgrInfo.

Last thing I can think of is an important safety tip. If plpython caches 
the compiled function, you need to take care to invalidate it if the 
return or argument types change from call to call.

> 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)

Joe


In response to

Responses

pgsql-patches by date

Next:From: Hannu KrosingDate: 2003-04-08 19:47:03
Subject: Re: array support patch phase 1 patch
Previous:From: Tom LaneDate: 2003-04-08 16:37:07
Subject: Re: array support patch phase 1 patch

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