...
> Here again the column cannot be named without using quotes. But I'd
> see issuing a warning about it as unwarranted nannyism.
Yup. I'm not suggesting a change, but the more explicit discussion on
*why* this may be acceptable is probably helpful. I think we are pretty
close in 'tude on the
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> avi=> create view z as select x as user from y;
> My expected result: an error message in CREATE VIEW
>> This is not a bug, it is intentional behavior. "AS" names are not
>> restricted to be non-reserved words.
> Sure, but his point is that the resul
> > avi=> create view z as select x as user from y;
> > My expected result: an error message in CREATE VIEW
> This is not a bug, it is intentional behavior. "AS" names are not
> restricted to be non-reserved words.
Sure, but his point is that the resulting view has a column which is
named "use
[EMAIL PROTECTED] writes:
> avi=> create view z as select x as user from y;
> My expected result: an error message in CREATE VIEW
This is not a bug, it is intentional behavior. "AS" names are not
restricted to be non-reserved words.
regards, tom lane
This is because user is a "reserved" word.
user is a macro for the function current_user()
Try this SQL: SELECT user;
It is best to change the table name from user to username;
However it is probably a wise idea for Postgres to emit some sort of error
on the create mentioning the reserved word
Avi Kivity ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
Keyword USER not detected in CREATE VIEW
Long Description
The reserved keyword USER is rejected in CREATE TABLE, as expected:
avi=> create table x (user varchar);
