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: http://www.postgresql.org/mailpref/pgsql-hackers