Re: proposal: plpgsql, solution for derivated types of parameters - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal: plpgsql, solution for derivated types of parameters
Date
Msg-id AANLkTimV2vsabxA6feTXkAL4qnQ9+2m=dH1qN8sF-QqF@mail.gmail.com
Whole thread Raw
In response to Re: proposal: plpgsql, solution for derivated types of parameters  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
2010/10/8 Tom Lane <tgl@sss.pgh.pa.us>:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> the current plpgsql syntax doesn't offer a functionality to define
>> some variable with type as element of some other array variable or
>> reverse order. The primary goal of this proposal is enahancing plpgsql
>> for better working with polymorphic types.
>
> I haven't seen any actual field complaints that would be solved by this.
> How often is it really going to be useful?
>
>> DECLARE elementvar IS ELEMENT OF arrayvar;
>> DECLARE arrayvar IS ARRAY OF varname;
>
> Both of these notations seem pretty inconsistent with the rest of
> plpgsql, as well as being dead ends when you think about extensions to
> more complex situations like arrays of records or records of arrays.
> I'd expect to do the former with something like "arrayvar[0]%type" and

uff  "arrayvar[0]%type" should be in plpgsql spirit? There is nothing
similar in Ada, PL/SQL or languages similar to modula. I don't see why
my proposal cannot work with more complex types. This is maybe C
construct - it must not be used for plpgsql - subscripts can start
with other number than zero.

DECLARE arrayvar IS ARRAY OF sometype

or

DECLARE arrayvar IS ARRAY OF somevar%type;

possible

DECLARE arrayvar IS ARRAY OF somerec.field%type;

This syntax is similar to Ada language.



> the latter with "var%type[]".  Possibly some parentheses would be needed
> to make this non-ambiguous.
>
>                        regards, tom lane
>


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Issues with Quorum Commit
Next
From: Pavel Stehule
Date:
Subject: Re: a few small bugs in plpgsql