From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Proposed ProcessUtility() API additions |
Date: | 2007-03-07 23:01:02 |
Message-ID: | 23588.1173308462@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I'd like to change ProcessUtility to take a couple of additional
parameters, which it in turn would pass down to those (relatively few)
utility statements that need one or both:
* query_string: source text of command, if known (can be NULL)
* is_top_level: TRUE if command is being driven directly from
exec_simple_query or exec_execute_message, else FALSE (this would
need to be passed through PortalRun, so it gets this parameter added
too).
The point of adding query_string is that whenever parse analysis of
a sub-command is postponed until utility execution, we need to pass
the query string to parse_analyze if we want syntax error location.
This is already an issue for CREATE SCHEMA, and it's about to be
a problem for PREPARE. There are also a couple of places that rely
on debug_query_string, which they really shouldn't be doing since
that's the current interactive command, not necessarily what's being
parsed at the moment.
The point of adding is_top_level is to provide a simpler, more reliable
means for PreventTransactionChain and related functions to detect
whether a function is trying to invoke a non-transaction-block-safe
command. Currently we rely on an ugly test involving seeing if the
statement node is in the QueryContext, but that's always been a kluge,
and I'm not sure that it works 100% even today. I'd like to get rid
of the QueryContext global altogether.
Comments, objections?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-03-07 23:18:44 | Re: RFC: changing autovacuum_naptime semantics |
Previous Message | Alvaro Herrera | 2007-03-07 23:00:01 | RFC: changing autovacuum_naptime semantics |