diff options
author | Bruce Momjian <bruce@momjian.us> | 1999-12-16 20:07:41 +0000 |
---|---|---|
committer | Bruce Momjian <bruce@momjian.us> | 1999-12-16 20:07:41 +0000 |
commit | cf374febf5a06dfbf02f5d6d74f5d156cb9af62a (patch) | |
tree | fa9fbf811335762bf0b537239fe0798da59a61e1 /src/backend/executor/_deadcode | |
parent | 99b8f8451170a5c2fc130426952819502c10aea9 (diff) | |
download | postgresql-cf374febf5a06dfbf02f5d6d74f5d156cb9af62a.tar.gz postgresql-cf374febf5a06dfbf02f5d6d74f5d156cb9af62a.zip |
>Turning nextval and currval into keywords is not an acceptable way to
>go about this. That will risk breaking existing applications that use
>those names as column names.
>
>It should actually almost work to write sq.nextval as things stand,
>because Postgres has for a long time considered table.function and
>function(table) to be interchangeable notations for certain kinds of
>functions. nextval doesn't seem to be one of that kind of function,
>at the moment. I'd suggest leaving the grammar as it was, and taking a
>look at ParseFuncOrColumn in parse_func.c to see if you can't persuade
>it to accept the sequence functions in that style.
OK, good point. I tried to implement it somewhere else and ended up
extending transformAttr. Attached you'll find the patch.
Jeroen van Vianen
Diffstat (limited to 'src/backend/executor/_deadcode')
0 files changed, 0 insertions, 0 deletions