Re: array support patch phase 1 patch - Mailing list 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