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 |
Message-ID: | 56E6DFFA.9090502@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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: http://www.postgrespro.com
Russian Postgres Company
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 |