On Tue, Jan 3, 2017 at 12:06 AM, Ashutosh Bapat
<ashutosh.bapat@enterprisedb.com> wrote:
> Instead of changing get_object_address_unqualified(),
> get_object_address_unqualified() and pg_get_object_address(), should
> we just stick get_database_name(MyDatabaseId) as object name in
> gram.y?
No. Note this comment at the top of gram.y:
* In general, nothing in this file should initiate database accesses* nor depend on changeable state
(suchas SET variables). If you do* database accesses, your code will fail when we have aborted the*
currenttransaction and are just parsing commands to find the next* ROLLBACK or COMMIT. If you make use of SET
variables,then you* will do the wrong thing in multi-query strings like this:* SET
constraint_exclusionTO off; SELECT * FROM foo;* because the entire string is parsed by gram.y before the SET
gets* executed. Anything that depends on the database or changeable state* should be handled during parse
analysisso that it happens at the* right time not the wrong time.
I grant you that MyDatabaseId can't (currently, anyway) change during
the lifetime of a single backend, but it still seems like a bad idea
to make gram.y depend on that. If nothing else, it's problematic if
we want to deparse the DDL statement (as Fabrízio also points out).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company