Re: plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types - Mailing list pgsql-hackers
From | Artur Zakirov |
---|---|
Subject | Re: plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types |
Date | |
Msg-id | 56E6DFFA.9090502@postgrespro.ru Whole thread Raw |
In response to | Re: plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types (Tom Lane <tgl@sss.pgh.pa.us>) |
List | pgsql-hackers |
On 14.03.2016 17:54, Tom Lane wrote: > Joe Conway <mail@joeconway.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
pgsql-hackers by date: