Re: [HACKERS] Missing array support

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] Missing array support
Date: 2003-06-30 21:27:38
Message-ID: 17681.1057008458@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Joe Conway <mail(at)joeconway(dot)com> writes:
> Do I have until midnite PDT, or EDT?

We hadn't actually set a formal deadline time AFAIR. Midnight your
local time is fine with me.

Thinking about this further, it occurs to me that there's no hard reason
plpgsql (and other PLs that adopt the we-can-convert-anything-to-string
philosophy, such as pltcl) couldn't allow arguments (though not results)
of type ANY. It's not different from accepting ANYELEMENT as far as the
runtime mechanisms are concerned. The only difference is in
constraining multiple arguments and/or the result to be of the same or
related types, which is not really an issue that affects the PL directly.

As far as the other point goes, I plan to change resolve_type to be like

resolve_polymorphic_type(declared_type, context_actual_type,
context_declared_type)

where context_actual_type is the actual datatype passed to an argument
of declared type context_declared_type, and declared_type is the
declared type of some argument or result that you want to resolve (not
necessarily the same argument). So the rules are

1. declared_type not polymorphic -> return it as-is.

2. declared_type polymorphic, but context_declared_type not polymorphic
-> raise error ("can't resolve").

3. Otherwise there are four possible combinations:

declared_type context_declared_type action

ANYELEMENT ANYELEMENT return context_actual_type
ANYELEMENT ANYARRAY return get_element_type(context_actual_type)
(raise error if it fails)
ANYARRAY ANYELEMENT return get_array_type(context_actual_type)
(raise error if it fails)
ANYARRAY ANYARRAY check context_actual_type is an
array, then return it

This should work as long as the parser has previously done
enforce_generic_type_consistency on the call. I'm still not convinced
that there is any application for it outside of deriving a polymorphic
aggregate's state type, though.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-06-30 21:32:18 Re: PlPython
Previous Message elein 2003-06-30 21:14:09 Re: PlPython

Browse pgsql-patches by date

  From Date Subject
Next Message Joe Conway 2003-06-30 23:14:42 Re: polymorphic arguments and return type for PL/pgSQL
Previous Message Jean-Michel POURE 2003-06-30 21:24:08 Re: pgAdmin3 translation request into Hungarian