plpgsql has an enum called IdentifierLookup which includes a value
IDENTIFIER_LOOKUP_EXPR which is declared like this:
IDENTIFIER_LOOKUP_EXPR /* In SQL expression --- special case */
It regrettably does not explain what exactly is special about it, and
AFAICT, neither does any other comment. If I replace every usage of
IDENTIFIER_LOOKUP_EXPR with IDENTIFIER_LOOKUP_NORMAL, the regression
tests pass nonetheless. It was introduced by
01f7d29902cb27fb698e5078d72cb837398e074c, committed by Tom in 2010:
commit 01f7d29902cb27fb698e5078d72cb837398e074c
Author: Tom Lane <t...@sss.pgh.pa.us>
Date: Sun Jan 10 17:15:18 2010 +0000
Improve plpgsql's handling of record field references by forcing
all potential
field references in SQL expressions to have RECFIELD datum-array entries at
parse time. If it turns out that the reference is actually to a SQL column,
the RECFIELD entry is useless, but it costs little. This allows
us to get rid
of the previous use of FieldSelect applied to a whole-row Param
for the record
variable; which was not only slower than a direct RECFIELD reference, but
failed for references to system columns of a trigger's NEW or OLD record.
Per report and fix suggestion from Dean Rasheed.
The rule, as far as I can tell from reading the code, is that
IDENTIFIER_LOOKUP_NORMAL looks up words, double-words (e.g. x.y), and
triple-words (e.g x.y.z), IDENTIFIER_LOOKUP_EXPR looks up only
double-words and triple-words, and IDENTIFIER_LOOKUP_DECLARE looks up
nothing. But it's not clear to me exactly what the motivation for
that is. plpgsql_parse_word says:
/*
* We should do nothing in DECLARE sections. In SQL expressions, there's
* no need to do anything either --- lookup will happen when the
* expression is compiled.
*/
...but that doesn't really explain why we go out of our way to have
this third state, because the wording implies that it doesn't
particularly matter one way or the other.
Any help appreciated.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
