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:

Previous
From: David Steele
Date:
Subject: Re: Fuzzy substring searching with the pg_trgm extension
Next
From: Stephen Frost
Date:
Subject: Re: pg_dump dump catalog ACLs