From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Artur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
Subject: | Re: plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types |
Date: | 2016-03-14 16:04:41 |
Message-ID: | 31754.1457971481@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> However ... one thing I was intending to mention on this thread is that
> "get the array type over this type" isn't the only extension one might
> wish for. Another likely desire is "get the type of field 'foo' of this
> composite type". I don't suggest that this patch needs to implement
> that right now; but it would be a good thing if we could see how the
> chosen syntax could be extended in such a direction. Otherwise we might
> be painting ourselves into a corner.
To enlarge a little bit: it seems to me that what we're really wishing for
here is a type name syntax that goes beyond simple names. If we were
starting in a green field, we might choose a recursively-composable syntax
like the following.
type_name can be:
* A simple type name, such as int8 or varchar[42].
* TYPE_OF(expression), meaning that the SQL expression is parsed but never
executed, we just take this construct as naming its result type.
* ARRAY_OF(type_name), meaning the array type having type_name as its
element type.
* ELEMENT_OF(type_name), meaning the element type of the array type
named by type_name.
* ROW_OF(type_name [, type_name ...]), meaning the composite type with
those types as columns.
* FIELD_OF(type_name, foo), meaning the type of column "foo" of the
composite type named by type_name. I'm not sure if there would be
use-cases for selecting a column other than by a simple literal name,
but there could be variants of this function if so.
It's possible to think of other cases, for example what about range
types? You could allow ELEMENT_OF() to apply to range types, certainly.
I'm not sure about the other direction, because multiple range types
could have the same element type; but it's possible to hope that some
type-naming function along the lines of RANGE_OF(type_name, other args)
could disambiguate. The main reason I'm thinking of a function-like
syntax here is that it can easily handle additional arguments when
needed.
Comparing this flight of fancy to where we are today, we have
%TYPE as a remarkably ugly and limited implementation of TYPE_OF(),
and we have the precedent that foo[] means ARRAY_OF(foo). I'm not
sure how we get any extensibility out of either of those things.
Or in short: maybe it's time to blow up %TYPE and start fresh.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2016-03-14 16:06:07 | Re: Password identifiers, protocol aging and SCRAM protocol |
Previous Message | Alvaro Herrera | 2016-03-14 16:01:04 | Re: [patch] Proposal for \crosstabview in psql |