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

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

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


pgsql-hackers by date

Next:From: Tom LaneDate: 2003-06-30 21:32:18
Subject: Re: PlPython
Previous:From: eleinDate: 2003-06-30 21:14:09
Subject: Re: PlPython

pgsql-patches by date

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

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