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