Tim Hart <tjhart@mac.com> writes:
> At the time I executed the statement
> create type position as enum('pitcher', 'catcher', 'first base',
> 'second base', 'third base', 'short stop', 'left field', 'center
> field', 'right field', 'designated hitter', 'pinch hitter');
> Would it have been reasonable to expect some kind of notice or warning
> message stating that 'position' was special, and
Perhaps, although I'm not sure how to do that without generating
nuisance warnings in some cases. One problem is that the CREATE TYPE
code has no idea whether you typed position or "position", and surely
a warning wouldn't be desirable in the second case.
> <double-quote>position<double-quote> would be used instead?
The way you phrase that makes me think you misunderstand what's
happening here. The name of the type isn't "position" with double
quotes, it's just position. You have to double-quote it when you
use it to prevent the parser from thinking that the special SQL
POSITION function call syntax is coming up. There are other ways
to do that though, for example if you write public.position (or whatever
schema it's in) then you won't need double quotes.
> Given the non-trivial list of reserved and non-reserved words, I can
> imagine that this situation has risen before - and probably will again.
Yeah, the SQL committee is doing no one any favors with their fondness
for bizarre special-case syntax for what could be perfectly ordinary
function calls. In the example at hand, this is actually completely
ambiguous:
position('a' in ('b'))
Is that a single argument that happens to be a degenerate IN-scalar-list
expression, or is it a spec-compliant invocation of 2-argument POSITION?
Experimentation shows that PG thinks it's the latter, but I sure
wouldn't have taken a bet on that in advance.
regards, tom lane
