Proposed ProcessUtility() API additions

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

Responses

Browse pgsql-hackers by date

  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