2016-04-25 19:40 GMT+02:00 Bruce Momjian <br...@momjian.us>: > > Good summary. Is there a TODO item here? >
no, it is not Regars Pavel > > --------------------------------------------------------------------------- > > 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 (pgsql-hackers@postgresql.org) > > To make changes to your subscription: > > http://www.postgresql.org/mailpref/pgsql-hackers > > -- > Bruce Momjian <br...@momjian.us> http://momjian.us > EnterpriseDB http://enterprisedb.com > > + As you are, so once was I. As I am, so you will be. + > + Ancient Roman grave inscription + >
