info is a reserved word?
I have two identical functions below, the only difference is I
declared my variable name to be 'info' instead of 'stuff'. I could
not find anywhere in the docs that 'info' has any special meaning.
Did I miss it?
create type my_info as (
a text,
b text
);
-- this works
create or replace function my_stuff ()
returns my_info as $$
declare
stuff my_info;
begin
stuff.a := 'hi';
stuff.b := 'there';
return stuff;
end;
$$ language plpgsql;
create or replace function my_stuff ()
returns my_info as $$
declare
info my_info;
begin
info.a := 'hi';
info.b := 'there';
return info;
end;
$$ language plpgsql;
Evaluating this definition gives:
psql:16: ERROR: syntax error at or near "info" at character 71
psql:16: LINE 4: info my_info;
psql:16: ^
pg 8.1.1, OS X 10.4.3
John DeSoi, Ph.D.
http://pgedit.com/
Power Tools for PostgreSQL
On Thu, Jan 12, 2006 at 08:14:42PM -0500, John DeSoi wrote:
I have two identical functions below, the only difference is I
declared my variable name to be 'info' instead of 'stuff'. I could
not find anywhere in the docs that 'info' has any special meaning.
'info' only seems special in PL/pgSQL, presumably because it's one
of the possible RAISE levels. You should also get an error if you
try 'exception', 'warning', etc.
--
Michael Fuhr
Michael Fuhr <mike@fuhr.org> writes:
'info' only seems special in PL/pgSQL, presumably because it's one
of the possible RAISE levels. You should also get an error if you
try 'exception', 'warning', etc.
plpgsql is not very good about reserving words "minimally", ie, not
treating a word as a keyword outside the context where the keyword
is meaningful.
This could probably be fixed, or at least greatly reduced, with some
flex/bison hacking. Anyone up for it?
regards, tom lane
On Thu, Jan 12, 2006 at 11:21:28PM -0500, Tom Lane wrote:
plpgsql is not very good about reserving words "minimally", ie, not
treating a word as a keyword outside the context where the keyword
is meaningful.This could probably be fixed, or at least greatly reduced, with some
flex/bison hacking. Anyone up for it?
Possibly. Would it involve much more than what the main parser's
grammar does with unreserved_keyword and friends? I suppose this
ought to move to pgsql-hackers.
--
Michael Fuhr
[ moved to -hackers ]
Michael Fuhr <mike@fuhr.org> writes:
On Thu, Jan 12, 2006 at 11:21:28PM -0500, Tom Lane wrote:
plpgsql is not very good about reserving words "minimally", ie, not
treating a word as a keyword outside the context where the keyword
is meaningful.This could probably be fixed, or at least greatly reduced, with some
flex/bison hacking. Anyone up for it?
Possibly. Would it involve much more than what the main parser's
grammar does with unreserved_keyword and friends? I suppose this
ought to move to pgsql-hackers.
The keyword-classification tactic would be one approach. For the
specific case of the RAISE severity codes, I'd be inclined to eliminate
all those "keywords" entirely and let them be lexed/parsed as simple
identifiers --- there's no strong reason not to do strcmp's for specific
identifiers at the point where we're building a raise_level value.
There are probably some other methods that might apply in other places.
But in any case it's a fairly self-contained problem; you don't need
any vast knowledge of Postgres internals to tackle it, just some
understanding of the flex and bison tools.
regards, tom lane