On Tue, Jan 3, 2017 at 12:06 AM, Ashutosh Bapat
<ashutosh.ba...@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 (such as SET variables).  If you do
 *        database accesses, your code will fail when we have aborted the
 *        current transaction 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_exclusion TO 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 analysis so 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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to