Re: plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types - Mailing list pgsql-hackers
| From | Pavel Stehule |
|---|---|
| Subject | Re: plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types |
| Date | |
| Msg-id | CAFj8pRBsTp_ODUG2fg7QL+JbZw+n32AMgqBe=9nEf_LOFW=AUQ@mail.gmail.com 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>) |
| Responses |
Re: plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types
Re: plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types |
| List | pgsql-hackers |
2016-03-14 20:38 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Mar 14, 2016 at 12:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Or in short: maybe it's time to blow up %TYPE and start fresh.
> That's not a dumb idea. I think %TYPE is an Oracle-ism, and it
> doesn't seem to have been their best-ever design decision.
Using %TYPE has sense in PostgreSQL too. It is protection against a domain's explosion - I don't need to declare the domains like varchar_10, varchar_100, etc. It does more work in Oracle due living relation between table columns and PL/SQL variables - but this differences are same for domain types in PL/pgSQL. What is redundant in Postgres, is using %TYPE and %ROWTYPE. Because native PL languages has strong relation to system catalog I see this feature like well designed and helpful. Some different can be our implementation.
It is, and it wasn't. What concerns me about the present patch is
that it's trying to shoehorn more functionality into something that
was badly designed to start with. I think we'd be better off leaving
%TYPE as a deprecated backwards-compatibility feature and inventing
something new and more extensible.
I'm not wedded to any part of the syntax I just wrote, but I do say
that we need something that allows composability of type selectors.
Last version of this patch doesn't modify %TYPE part - and the implemented syntax is near to your proposed (not all cases), and near to ADA syntax. But, probably, you are unhappy with it.
Can you describe your expectations from this feature little bit more, please?
We can leave the original discussion about %TYPE. It was my mistake. I push two different ingredients to one soup.
We can leave the original discussion about %TYPE. It was my mistake. I push two different ingredients to one soup.
There are two independent features - referenced types - the original %TYPE and %ROWTYPE features, the possibility to take type from system catalog information.
Last patch implements linear ELEMENT OF ... , ARRAY OF ... . Can be solution recursive enhancing of last patch? We can implement other type modificator like RANGE OF (any other?)Then we can write some like
ARRAY OF RANGE OF int; or ELEMENT OF ELEMENT OF array_of_ranges
or if we use functional syntax
ARRAY_OF(RANGE_OF(int))
I prefer non functional syntax - it looks more natural in DECLARE part, but it is detail in this moment. I can live with functional syntax too. The functional syntax is easy parserable, but the SQL is not functional - so I see it foreign there.
Where you are expecting the implementation? In PLpgSQL only, or generally in DDL, or in both levels?
Regards
Pavel
regards, tom lane
pgsql-hackers by date: