Re: plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

From: Artur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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>, 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 15:59:54
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 14.03.2016 17:54, Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)com> writes:
>> This new version of the patch was posted after the commitfest item was
>> marked ready for committer. Does anyone have further comments or
>> objections to the concept or syntax before I try to take this forward?
> The quoted excerpt fails to say what solution was adopted to the array
> syntax issues, so it's impossible to have an opinion without actually
> reading the patch.
> 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.
> regards, tom lane

I looked this patch and the previous. The patch applies correctly to
HEAD. Regression tests pass successfully, without errors.

In comparison with the previous patch it adds the following functionality:
- %TYPE - now can be used for composite types (same syntax).
- %TYPE[] - new functionality, provides the array type from a
variable or table column (syntax was changed).
- var ELEMENT OF othervar%TYPE - new funcitonality, provides the element
type of a given array (syntax was changed).

Was changed plpgsql_derive_type(). Now it has the following definition:

> PLpgSQL_type *
> plpgsql_derive_type(PLpgSQL_type *base_type, bool to_element_type, bool to_array_type)

Previously it had the following definition:

> static PLpgSQL_type *
> derive_type(PLpgSQL_type *base_type, PLpgSQL_reftype reftype)

where PLpgSQL_reftype was the enum:

> + typedef enum
> + {
> + PLPGSQL_REFTYPE_TYPE, /* use type of some variable */
> + PLPGSQL_REFTYPE_ELEMENT, /* use a element type of referenced variable */
> + PLPGSQL_REFTYPE_ARRAY /* use a array type of referenced variable */
> + } PLpgSQL_reftype;

I think the previous version was better, because enum is better than
additional function parameters. But it is only for me.

Also there is a little typo here:

> + * This routine is used for generating element or array type from base type.
> + * The options to_element_type and to_array_type can be used together, when
> + * we would to ensure valid result. The array array type is original type, so
> + * this direction is safe. The element of scalar type is not allowed, but if
> + * we do "to array" transformation first, then this direction should be safe
> + * too. This design is tolerant, because we should to support a design of
> + * polymorphic parameters, where a array value can be passed as anyelement
> + * or anyarray parameter.
> + */
> + PLpgSQL_type *
> + plpgsql_derive_type(PLpgSQL_type *base_type,

Here the word "array" occurs two times in the third line.

Artur Zakirov
Postgres Professional:
Russian Postgres Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2016-03-14 16:00:57 Re: pg_dump dump catalog ACLs
Previous Message David Steele 2016-03-14 15:48:28 Re: Fuzzy substring searching with the pg_trgm extension