Good summary. Is there a TODO item here?
On Tue, Mar 15, 2016 at 08:17:07PM -0400, Tom Lane wrote:
> Pavel Stehule <pavel.steh...@gmail.com> writes:
> >> Robert Haas <robertmh...@gmail.com> writes:
> >>> 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's certainly useful functionality; the question is whether this
> particular syntax is an appropriate base for extended features.
> As I see it, what we're talking about here could be called type operators:
> given a type name or some other kind of SQL expression, produce the name
> of a related type. The existing things of that sort are %TYPE and 
> (we don't really implement  as a type operator, but a user could
> reasonably think of it as one). This patch proposes to make %TYPE and 
> composable into a single operator, and then it proposes to add ELEMENT OF
> as a different operator; and these things are only implemented in plpgsql.
> My concern is basically that I don't want to stop there. I think we want
> more type operators in future, such as the rowtype-related operators
> I sketched upthread; and I think we will want these operators anywhere
> that you can write a type name.
> Now, in the core grammar we have  which can be attached to any type
> name, and we have %TYPE but it only works in very limited contexts.
> There's a fundamental problem with extending %TYPE to be used anywhere
> a type name can: consider
> select 'foo'::x%type from t;
> It's ambiguous whether this is an invocation of %TYPE syntax or whether %
> is meant to be a regular operator and TYPE the name of a variable. Now,
> we could remove that ambiguity by promoting TYPE to be a fully reserved
> word (it is unreserved today). But that's not very palatable, and even
> if we did reserve TYPE, I think we'd still need a lexer kluge to convert
> %TYPE into a single token, else bison will have lookahead problems.
> That sort of kluge is ugly, costs performance, and tends to have
> unforeseen side-effects.
> So my opinion is that rather than extending %TYPE, we need a new syntax
> that is capable of being used in more general contexts.
> There's another problem with the proposal as given: it adds a prefix
> type operator (ELEMENT OF) where before we only had postfix ones.
> That means there's an ambiguity about which one binds tighter. This is
> not a big deal right now, since there'd be little point in combining
> ELEMENT OF and  in the same operation, but it's going to create a mess
> when we try to add additional type operators. You're going to need to
> allow parentheses to control binding order. I also find it unsightly
> that the prefix operator looks so little like the postfix operators
> syntactically, even though they do very similar sorts of things.
> In short there basically isn't much to like about these syntax details.
> I also do not like adding the feature to plpgsql first. At best, that's
> going to be code we throw away when we implement the same functionality
> in the core's typename parser. At worst, we'll have a permanent
> incompatibility because we find we can't make the core parser use exactly
> the same syntax. (For example, it's possible we'd find out we have to
> make ELEMENT a fully-reserved word in order to use this ELEMENT OF syntax.
> Or maybe it's fine; but until we've tried to cram it into the Typename
> production, we won't know. I'm a bit suspicious of expecting it to be
> fine, though, since AFAICS this patch breaks the ability to use "element"
> as a plain type name in a plpgsql variable declaration. Handwritten
> parsing code like this tends to be full of such gotchas.)
> In short, I think we should reject this implementation and instead try
> to implement the type operators we want in the core grammar's Typename
> production, from which plpgsql will pick it up automatically. That is
> going to require some other syntax than this. As I said, I'm not
> particularly pushing the function-like syntax I wrote upthread; but
> I want to see something that is capable of supporting all those features
> and can be extended later if we think of other type operators we want.
> regards, tom lane
> Sent via pgsql-hackers mailing list (email@example.com)
> To make changes to your subscription:
Bruce Momjian <br...@momjian.us> http://momjian.us
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: