Re: [HACKERS] Proposed ProcessUtility() API additions
Tom Lane wrote: 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. Great! I once played with the idea of using a simpler MemoryContext implementation in the parser to save some CPU cycles, and PreventTransactionChain stopped working. I don't know if what I was doing was a good idea, but PreventTransactionChain is definitely a hack. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Proposed ProcessUtility() API additions
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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Proposed ProcessUtility() API additions
Tom Lane [EMAIL PROTECTED] writes: * 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 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. I'm not exactly following. How does the exec_simple_query or exec_execute_message tell you whether you're in a transaction? Can't you exec_simple_query(BEGIN;) and then exec_simple_query a second query in the same transaction? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Proposed ProcessUtility() API additions
Gregory Stark [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: 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. I'm not exactly following. How does the exec_simple_query or exec_execute_message tell you whether you're in a transaction? Read PreventTransactionChain and friends. We can tell from state info provided by xact.c whether we're inside a BEGIN block. The problem stems from cases like SELECT myfunc() where myfunc() tries to execute one of the verboten commands, via SPI or some similar mechanism. If we allowed that, then the function could try to execute more commands within the same top-level transaction, which is exactly what we don't want to allow. If the command is being issued directly by exec_simple_query or exec_execute_message, and it's not inside a BEGIN block, then there's no way for an additional command to be issued before commit. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
