Re: SQL99 ARRAY support proposal

From: Joe Conway <mail(at)joeconway(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Hannu Krosing <hannu(at)tm(dot)ee>, "Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SQL99 ARRAY support proposal
Date: 2003-03-10 16:27:08
Message-ID: 3E6CBCDC.10005@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Tom Lane wrote:
> But I think I like better the notion of extending my bound-together-
> ANYARRAY-and-ANYELEMENT proposal,
> http://archives.postgresql.org/pgsql-hackers/2003-03/msg00319.php
>
> Suppose that we do that, and then further say that ANYARRAY or
> ANYELEMENT appearing as the return type implies that the return type
> is actually the common element or array type. Then we have such
> useful behaviors as:
>
> array_push(anyarray, anyelement) returns anyarray
> array_pop(anyarray) returns anyelement
> array_subscript(anyarray, int) yields anyelement
> singleton_array(anyelement) yields anyarray
>
> The last three cases cannot be handled by a SAMEASPARAM construct.

That was my concern also. I like the above.

So if I understand correctly, all instances of anyarray and anyelement
in a function definition would need to be self-consistent, but the group
could represent essentially any datatype with its corresponding array
type. If we need more than one of these self consistent groups, we could
resort to anyarray1/anyelement1, etc. Does this sound correct?

Also, an implementation question: if I have a type oid for an element,
what is the preferred method for determining the corresponding array?
I'm thinking that the most efficient method might be to use the
element-type name with a '_' prepended to get the array-type oid, but
that seems ugly. Thoughts?

Thanks,

Joe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Clift 2003-03-10 16:28:48 Re: [GENERAL] division by zero
Previous Message Bruce Momjian 2003-03-10 16:26:00 Re: Cursors and backwards scans and SCROLL

Browse pgsql-patches by date

  From Date Subject
Next Message Neil Conway 2003-03-10 16:57:46 spelling corrections
Previous Message Bruce Momjian 2003-03-10 15:45:35 Re: String changes