… context struct. This reverts most of commit 0791252
estimation callers expect to only deal with Const nodes.
* Refactoring: Previously, all callers of simplify_function() did their own mutation of argument lists prior to calling. Also, arguments added in reorder_function_arguments() and add_function_defaults() were mutated separately in those functions. Now all of that is done in one place, in simplify_function(). This also reduces iterations over the argument list. reorder_function_arguments() and add_function_defaults() functions now don't get a context argument anymore. * Rename eval_const_expressions_mutator -> const_expressions_mutator This function doesn't just evaluate expressions anymore.
Choose a saner ordering of parameters (adding a new input param after the output params seemed a bit random), update the function's header comment to match reality (cmon folks, is this really that hard?), get rid of useless and sloppily-defined distinction between PROCESS_UTILITY_SUBCOMMAND and PROCESS_UTILITY_GENERATED.
We mustn't run any of the event-trigger support code when handling utility statements like START TRANSACTION or ABORT, because that code may need to refresh event-trigger cache data, which requires being inside a valid transaction. (This mistake explains the consistent build failures exhibited by the CLOBBER_CACHE_ALWAYS buildfarm members, as well as some irreproducible failures on other members.) The least messy fix seems to be to break standard_ProcessUtility into two functions, one that handles all the statements not supported by event triggers, and one that contains the event-trigger support code and handles the statements that are supported by event triggers. This change also fixes several inconsistencies, such as four cases where support had been installed for "ddl_event_start" but not "ddl_event_end" triggers, plus the fact that InvokeDDLCommandEventTriggersIfSupported() paid no mind to isCompleteQuery. Dimitri Fontaine and Tom Lane
Move checking for unscannable matviews into ExecOpenScanRelation, which is a better place for it first because the open relation is already available (saving a relcache lookup cycle), and second because this eliminates the problem of telling the difference between rangetable entries that will or will not be scanned by the query. In particular we can get rid of the not-terribly-well-thought-out-or-implemented isResultRel field that the initial matviews patch added to RangeTblEntry. Also get rid of entirely unnecessary scannability check in the rewriter, and a bogus decision about whether RefreshMatViewStmt requires a parse-time snapshot. catversion bump due to removal of a RangeTblEntry field, which changes stored rules.
The old phrasing appeared to imply that the failure was terminal. Improve that by indicating that archiving will be tried again later.
ORDER BY expressions were being treated the same as regular aggregate arguments for purposes of collation determination, but really they should not affect the aggregate's collation at all; only collations of the aggregate's regular arguments should affect it. In many cases this mistake would lead to incorrectly throwing a "collation conflict" error; but in some cases the corrected code will silently assign a different collation to the aggregate than before, for example agg(foo ORDER BY bar COLLATE "x") which will now use foo's collation rather than "x" for the aggregate. Given this risk and the lack of field complaints about the issue, it doesn't seem prudent to back-patch. In passing, rearrange code in assign_collations_walker so that we don't need multiple copies of the standard logic for computing collation of a node with children. (Previously, CaseExpr duplicated the standard logic, and we would have needed a third copy for Aggref without this change.) Andrew Gierth and David Fetter
…able is explicitly requested, either with a -t/--table switch of the table itself, or by -n/--schema switch of the schema containing the extension table. Patch reviewed by Vibhor Kumar and Dimitri Fontaine. Backpatched to 9.1 when the extension management facility was added.
There's probably no real bug here at present, so not backpatching. But it seems good to make these bits consistent with the rest of libpq, so as to avoid future surprises. Patch by me. Review by Tom Lane.
There was a high probability of two or more concurrent C.I.C. commands deadlocking just before completion, because each would wait for the others to release their reference snapshots. Fix by releasing the snapshot before waiting for other snapshots to go away. Per report from Paul Hinze. Back-patch to all active branches.
This was due to incomplete implementation of rowcount reporting for RMV, which was due to initial waffling on whether it should be provided. It seems unlikely to be a useful or universally available number as more sophisticated techniques for maintaining matviews are added, so remove the partial support rather than completing it. Per report of Jeevan Chalke, but with a different fix
This is new in 9.3devel.