aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/ruleutils.c
Commit message (Collapse)AuthorAge
...
* Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to beTom Lane2009-11-20
| | | | | | | | | | | checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
* Don't treat NEW and OLD as reserved words anymore. For the purposes of rulesTom Lane2009-11-05
| | | | | | | | it works just as well to have them be ordinary identifiers, and this gets rid of a number of ugly special cases. Plus we aren't interfering with non-rule usage of these names. catversion bump because the names change internally in stored rules.
* Un-break EXPLAIN for Append plans. I messed this up a few days ago whileTom Lane2009-10-28
| | | | | | adding the ModifyTable node type --- I had been thinking ModifyTable should replace Append as a special case in push_plan(), but actually both of them have to be special-cased.
* Fix AcquireRewriteLocks to be sure that it acquires the right lock strengthTom Lane2009-10-28
| | | | | | when FOR UPDATE is propagated down into a sub-select expanded from a view. Similar bug to parser's isLockedRel issue that I fixed yesterday; likewise seems not quite worth the effort to back-patch.
* When FOR UPDATE/SHARE is used with LIMIT, put the LockRows plan nodeTom Lane2009-10-28
| | | | | | | | | | | | | | | | | underneath the Limit node, not atop it. This fixes the old problem that such a query might unexpectedly return fewer rows than the LIMIT says, due to LockRows discarding updated rows. There is a related problem that LockRows might destroy the sort ordering produced by earlier steps; but fixing that by pushing LockRows below Sort would create serious performance problems that are unjustified in many real-world applications, as well as potential deadlock problems from locking many more rows than expected. Instead, keep the present semantics of applying FOR UPDATE after ORDER BY within a single query level; but allow the user to specify the other way by writing FOR UPDATE in a sub-select. To make that work, track whether FOR UPDATE appeared explicitly in sub-selects or got pushed down from the parent, and don't flatten a sub-select that contained an explicit FOR UPDATE.
* Support SQL-compliant triggers on columns, ie fire only if certain columnsTom Lane2009-10-14
| | | | | | | | | | | are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
* Split the processing of INSERT/UPDATE/DELETE operations out of execMain.c.Tom Lane2009-10-10
| | | | | | | | | | They are now handled by a new plan node type called ModifyTable, which is placed at the top of the plan tree. In itself this change doesn't do much, except perhaps make the handling of RETURNING lists and inherited UPDATEs a tad less klugy. But it is necessary preparation for the intended extension of allowing RETURNING queries inside WITH. Marko Tiikkaja
* Use pg_get_triggerdef in pg_dumpPeter Eisentraut2009-10-09
| | | | | | | | | | | Add a variant of pg_get_triggerdef with a second argument "pretty" that causes the output to be formatted in the way pg_dump used to do. Use this variant in pg_dump with server versions >= 8.5. This insulates pg_dump from most future trigger feature additions, such as the upcoming column triggers patch. Author: Itagaki Takahiro <itagaki.takahiro@oss.ntt.co.jp>
* Support use of function argument names to identify which actual argumentsTom Lane2009-10-08
| | | | | | | match which function parameters. The syntax uses AS, for example funcname(value AS arg1, anothervalue AS arg2) Pavel Stehule
* Improve unique-constraint-violation error messages to include the exactTom Lane2009-08-01
| | | | | | | | | values being complained of. In passing, also remove the arbitrary length limitation in the similar error detail message for foreign key violations. Itagaki Takahiro
* Support deferrable uniqueness constraints.Tom Lane2009-07-29
| | | | | | | | | | The current implementation fires an AFTER ROW trigger for each tuple that looks like it might be non-unique according to the index contents at the time of insertion. This works well as long as there aren't many conflicts, but won't scale to massive unique-key reassignments. Improving that case is a TODO item. Dean Rasheed
* Assorted minor refactoring in EXPLAIN.Tom Lane2009-07-24
| | | | | | | | | | This is believed to not change the output at all, with one known exception: "Subquery Scan foo" becomes "Subquery Scan on foo". (We can fix that if anyone complains, but it would be a wart, because the old code was clearly inconsistent.) The main intention is to remove duplicate coding and provide a cleaner base for subsequent EXPLAIN patching. Robert Haas
* Make backend header files C++ safePeter Eisentraut2009-07-16
| | | | | | | | | | | This alters various incidental uses of C++ key words to use other similar identifiers, so that a C++ compiler won't choke outright. You still (probably) need extern "C" { }; around the inclusion of backend headers. based on a patch by Kurt Harriman <harriman@acm.org> Also add a script cpluspluscheck to check for C++ compatibility in the future. As of right now, this passes without error for me.
* Tweak the core scanner so that it can be used by plpgsql too.Tom Lane2009-07-14
| | | | | | | | | | | | | | Changes: Pass in the keyword lookup array instead of having it be hardwired. (This incidentally allows elimination of some duplicate coding in ecpg.) Re-order the token declarations in gram.y so that non-keyword tokens have numbers that won't change when keywords are added or removed. Add ".." and ":=" to the set of tokens recognized by scan.l. (Since these combinations are nowhere legal in core SQL, this does not change anything except the precise wording of the error you get when you write this.)
* Move some declarations in the raw-parser header files to create a clearerTom Lane2009-07-12
| | | | | | | | | | distinction between the external API (parser.h) and declarations that only need to be visible within the raw parser code (gramparse.h, which now is only included by parser.c, gram.y, scan.l, and keywords.c). This is in preparation for the upcoming change to a reentrant lexer, which will require referencing YYSTYPE in the declarations of base_yylex and filtered_base_yylex, hence gram.h will have to be included by gramparse.h. We don't want any more files than absolutely necessary to depend on gram.h, so some cleanup is called for.
* 8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef listBruce Momjian2009-06-11
| | | | provided by Andrew.
* Fix failure to double-quote function argument names when needed, inTom Lane2009-06-09
| | | | | pg_get_function_arguments() and related functions. Per report from Andreas Nolte.
* Allow the second argument of pg_get_expr() to be just zero when deparsingTom Lane2009-05-26
| | | | | | | an expression that's not supposed to contain variables. Per discussion with Gevik Babakhani, this eliminates the need for an ugly kluge (namely, specifying some unrelated relation name). Remove one such kluge from pg_dump.
* Change EXPLAIN output so that subplans and initplans (particularly CTEs)Tom Lane2009-04-05
| | | | | | | | | | | are individually labeled, rather than just grouped under an "InitPlan" or "SubPlan" heading. This in turn makes it possible for decompilation of a subplan reference to usefully identify which subplan it's referencing. I also made InitPlans identify which parameter symbol(s) they compute, so that references to those parameters elsewhere in the plan tree can be connected to the initplan that will be executed. Per a gripe from Robert Haas about EXPLAIN output of a WITH query being inadequate, plus some longstanding pet peeves of my own.
* Fix an old problem in decompilation of CASE constructs: the ruleutils.c codeTom Lane2009-02-25
| | | | | | | | | | | looks for a CaseTestExpr to figure out what the parser did, but it failed to consider the possibility that an implicit coercion might be inserted above the CaseTestExpr. This could result in an Assert failure in some cases (but correct results if Asserts weren't enabled), or an "unexpected CASE WHEN clause" error in other cases. Per report from Alan Li. Back-patch to 8.1; problem doesn't exist before that because CASE was implemented differently.
* Fix executor/spi.h to follow our usual conventions for include files, ie,Tom Lane2009-01-07
| | | | | | | | | not include postgres.h nor anything else it doesn't directly need. Add #includes to calling files as needed to compensate. Per my proposal of yesterday. This should be noted as a source code change in the 8.4 release notes, since it's likely to require changes in add-on modules.
* Update copyright for 2009.Bruce Momjian2009-01-01
|
* Add a WINDOW attribute to CREATE FUNCTION, and teach pg_dump about it,Tom Lane2008-12-31
| | | | | | | | | | | so that user-defined window functions are possible. For the moment you'll have to write them in C, for lack of any interface to the WindowObject API in the available PLs, but it's better than no support at all. There was some debate about the best syntax for this. I ended up choosing the "it's an attribute" position --- the other approach will inevitably be more work, and the likely market for user-defined window functions is probably too small to justify it.
* Add some basic support for window frame clauses to the window-functionsTom Lane2008-12-31
| | | | | | | | patch. This includes the ability to force the frame to cover the whole partition, and the ability to make the frame end exactly on the current row rather than its last ORDER BY peer. Supporting any more of the full SQL frame-clause syntax will require nontrivial hacking on the window aggregate code, so it'll have to wait for 8.5 or beyond.
* Support window functions a la SQL:2008.Tom Lane2008-12-28
| | | | Hitoshi Harada, with some kibitzing from Heikki and Tom.
* When we added the ability to have zero-element ARRAY[] constructs by adding anTom Lane2008-12-19
| | | | | | explicit cast to show the intended array type, we forgot to teach ruleutils.c to print out such constructs properly. Found by noting bogus output from recent changes in polymorphism regression test.
* Code review for function default parameters patch. Fix numerous problems asTom Lane2008-12-18
| | | | | per recent discussions. In passing this also fixes a couple of bugs in the previous variadic-parameters patch.
* Default values for function argumentsPeter Eisentraut2008-12-04
| | | | Pavel Stehule, with some tweaks by Peter Eisentraut
* Fix up ruleutils.c for CTE features. The main problem was thatTom Lane2008-10-06
| | | | | | | | | | | | | | | | get_name_for_var_field didn't have enough context to interpret a reference to a CTE query's output. Fixing this requires separate hacks for the regular deparse case (pg_get_ruledef) and for the EXPLAIN case, since the available context information is quite different. It's pretty nearly parallel to the existing code for SUBQUERY RTEs, though. Also, add code to make sure we qualify a relation name that matches a CTE name; else the CTE will mistakenly capture the reference when reloading the rule. In passing, fix a pre-existing problem with get_name_for_var_field not working on variables in targetlists of SubqueryScan plan nodes. Although latent all along, this wasn't a problem until we made EXPLAIN VERBOSE try to print targetlists. To do this, refactor the deparse_context_for_plan API so that the special case for SubqueryScan is all on ruleutils.c's side.
* When expanding a whole-row Var into a RowExpr during ResolveNew(), attachTom Lane2008-10-06
| | | | | | | | | | | | the column alias names of the RTE referenced by the Var to the RowExpr. This is needed to allow ruleutils.c to correctly deparse FieldSelect nodes referencing such a construct. Per my recent bug report. Adding a field to RowExpr forces initdb (because of stored rules changes) so this solution is not back-patchable; which is unfortunate because 8.2 and 8.3 have this issue. But it only affects EXPLAIN for some pretty odd corner cases, so we can probably live without a solution for the back branches.
* Implement SQL-standard WITH clauses, including WITH RECURSIVE.Tom Lane2008-10-04
| | | | | | | | | | | | | There are some unimplemented aspects: recursive queries must use UNION ALL (should allow UNION too), and we don't have SEARCH or CYCLE clauses. These might or might not get done for 8.4, but even without them it's a pretty useful feature. There are also a couple of small loose ends and definitional quibbles, which I'll send a memo about to pgsql-hackers shortly. But let's land the patch now so we can get on with other development. Yoshiyuki Asaba, with lots of help from Tatsuo Ishii and Tom Lane
* Adjust psql's new \ef command to present an empty CREATE FUNCTION templateTom Lane2008-09-06
| | | | | | | | | | for editing if no function name is specified. This seems a much cleaner way to offer that functionality than the original patch had. In passing, de-clutter the error displays that are given for a bogus function-name argument, and standardize on "$function$" as the default delimiter for the function body. (The original coding would use the shortest possible dollar-quote delimiter, which seems to create unnecessarily high risk of later conflicts with the user-modified function body.)
* Implement a psql command "\ef" to edit the definition of a function.Tom Lane2008-09-06
| | | | | | | In support of that, create a backend function pg_get_functiondef(). The psql command is functional but maybe a bit rough around the edges... Abhijit Menon-Sen
* Add a bunch of new error location reports to parse-analysis error messages.Tom Lane2008-09-01
| | | | | There are still some weak spots around JOIN USING and relation alias lists, but most errors reported within backend/parser/ now have locations.
* Move exprType(), exprTypmod(), expression_tree_walker(), and related routinesTom Lane2008-08-25
| | | | | | into nodes/nodeFuncs, so as to reduce wanton cross-subsystem #includes inside the backend. There's probably more that should be done along this line, but this is a start anyway.
* Arrange to convert EXISTS subqueries that are equivalent to hashable INTom Lane2008-08-22
| | | | | | | | | | | | | | | | | | | | | | | subqueries into the same thing you'd have gotten from IN (except always with unknownEqFalse = true, so as to get the proper semantics for an EXISTS). I believe this fixes the last case within CVS HEAD in which an EXISTS could give worse performance than an equivalent IN subquery. The tricky part of this is that if the upper query probes the EXISTS for only a few rows, the hashing implementation can actually be worse than the default, and therefore we need to make a cost-based decision about which way to use. But at the time when the planner generates plans for subqueries, it doesn't really know how many times the subquery will be executed. The least invasive solution seems to be to generate both plans and postpone the choice until execution. Therefore, in a query that has been optimized this way, EXPLAIN will show two subplans for the EXISTS, of which only one will actually get executed. There is a lot more that could be done based on this infrastructure: in particular it's interesting to consider switching to the hash plan if we start out using the non-hashed plan but find a lot more upper rows going by than we expected. I have therefore left some minor inefficiencies in place, such as initializing both subplans even though we will currently only use one.
* Rearrange the querytree representation of ORDER BY/GROUP BY/DISTINCT itemsTom Lane2008-08-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | as per my recent proposal: 1. Fold SortClause and GroupClause into a single node type SortGroupClause. We were already relying on them to be struct-equivalent, so using two node tags wasn't accomplishing much except to get in the way of comparing items with equal(). 2. Add an "eqop" field to SortGroupClause to carry the associated equality operator. This is cheap for the parser to get at the same time it's looking up the sort operator, and storing it eliminates the need for repeated not-so-cheap lookups during planning. In future this will also let us represent GROUP/DISTINCT operations on datatypes that have hash opclasses but no btree opclasses (ie, they have equality but no natural sort order). The previous representation simply didn't work for that, since its only indicator of comparison semantics was a sort operator. 3. Add a hasDistinctOn boolean to struct Query to explicitly record whether the distinctClause came from DISTINCT or DISTINCT ON. This allows removing some complicated and not 100% bulletproof code that attempted to figure that out from the distinctClause alone. This patch doesn't in itself create any new capability, but it's necessary infrastructure for future attempts to use hash-based grouping for DISTINCT and UNION/INTERSECT/EXCEPT.
* Implement SQL-spec RETURNS TABLE syntax for functions.Tom Lane2008-07-18
| | | | | | | (Unlike the original submission, this patch treats TABLE output parameters as being entirely equivalent to OUT parameters -- tgl) Pavel Stehule
* Add a "provariadic" column to pg_proc to eliminate the remarkably expensiveTom Lane2008-07-16
| | | | | | | | | | need to deconstruct proargmodes for each pg_proc entry inspected by FuncnameGetCandidates(). Fixes function lookup performance regression caused by yesterday's variadic-functions patch. In passing, make pg_proc.probin be NULL, rather than a dummy value '-', in cases where it is not actually used for the particular type of function. This should buy back some of the space cost of the extra column.
* Support "variadic" functions, which can accept a variable number of argumentsTom Lane2008-07-16
| | | | | | | | | | | | | | so long as all the trailing arguments are of the same (non-array) type. The function receives them as a single array argument (which is why they have to all be the same type). It might be useful to extend this facility to aggregates, but this patch doesn't do that. This patch imposes a noticeable slowdown on function lookup --- a follow-on patch will fix that by adding a redundant column to pg_proc. Pavel Stehule
* Fix pg_get_ruledef() so that negative numeric constants are parenthesized.Tom Lane2008-06-06
| | | | | | | | | | This is needed because :: casting binds more tightly than minus, so for example -1::integer is not the same as (-1)::integer, and there are cases where the difference is important. In particular this caused a failure in SELECT DISTINCT ... ORDER BY ... where expressions that should have matched were seen as different by the parser; but I suspect that there could be other cases where failure to parenthesize leads to subtler semantic differences in reloaded rules. Per report from Alexandr Popov.
* Restructure some header files a bit, in particular heapam.h, by removing someAlvaro Herrera2008-05-12
| | | | | | | | | | | | unnecessary #include lines in it. Also, move some tuple routine prototypes and macros to htup.h, which allows removal of heapam.h inclusion from some .c files. For this to work, a new header file access/sysattr.h needed to be created, initially containing attribute numbers of system columns, for pg_dump usage. While at it, make contrib ltree, intarray and hstore header files more consistent with our header style.
* The 8.2 patch that added support for an alias on the target table ofTom Lane2008-05-03
| | | | | UPDATE/DELETE forgot to teach ruleutils.c to display the alias. Per bug #4141 from Mathias Seiler.
* Support statement-level ON TRUNCATE triggers. Simon RiggsTom Lane2008-03-28
|
* Move the HTSU_Result enum definition into snapshot.h, to avoid includingAlvaro Herrera2008-03-26
| | | | | | tqual.h into heapam.h. This makes all inclusion of tqual.h explicit. I also sorted alphabetically the includes on some source files.
* Simplify and standardize conversions between TEXT datums and ordinary CTom Lane2008-03-25
| | | | | | | | | | | | | | | | | | | | strings. This patch introduces four support functions cstring_to_text, cstring_to_text_with_len, text_to_cstring, and text_to_cstring_buffer, and two macros CStringGetTextDatum and TextDatumGetCString. A number of existing macros that provided variants on these themes were removed. Most of the places that need to make such conversions now require just one function or macro call, in place of the multiple notational layers that used to be needed. There are no longer any direct calls of textout or textin, and we got most of the places that were using handmade conversions via memcpy (there may be a few still lurking, though). This commit doesn't make any serious effort to eliminate transient memory leaks caused by detoasting toasted text objects before they reach text_to_cstring. We changed PG_GETARG_TEXT_P to PG_GETARG_TEXT_PP in a few places where it was easy, but much more could be done. Brendan Jurd and Tom Lane
* A long time ago, Peter pointed out that ruleutils.c didn't dump simpleTom Lane2008-01-06
| | | | | | | | | | | | | | | | constant ORDER/GROUP BY entries properly: http://archives.postgresql.org/pgsql-hackers/2001-04/msg00457.php The original solution to that was in fact no good, as demonstrated by today's report from Martin Pitt: http://archives.postgresql.org/pgsql-bugs/2008-01/msg00027.php We can't use the column-number-reference format for a constant that is a resjunk targetlist entry, a case that was unfortunately not thought of in the original discussion. What we can do instead (which did not work at the time, but does work in 7.3 and up) is to emit the constant with explicit ::typename decoration, even if it otherwise wouldn't need it. This is sufficient to keep the parser from thinking it's a column number reference, and indeed is probably what the user must have done to get such a thing into the querytree in the first place.
* Update copyrights in source tree to 2008.Bruce Momjian2008-01-01
|
* When given a nonzero column number, pg_get_indexdef() is only supposed toTom Lane2007-12-20
| | | | | | | | | print the index key variable or expression for that column. It was mistakenly printing ASC/DESC/NULLS FIRST/NULLS LAST decoration too --- and not only for the target column, but all columns. Someday we should have an option to extract that info (and the opclass decoration as well) for a single index column ... but today is not that day. Per bug #3829 and subsequent discussion.
* Code review for LIKE ... INCLUDING INDEXES patch. Fix failure to propagateTom Lane2007-12-01
| | | | | | | | | | constraint status of copied indexes (bug #3774), as well as various other small bugs such as failure to pstrdup when needed. Allow INCLUDING INDEXES indexes to be merged with identical declared indexes (perhaps not real useful, but the code is there and having it not apply to LIKE indexes seems pretty unorthogonal). Avoid useless work in generateClonedIndexStmt(). Undo some poorly chosen API changes, and put a couple of routines in modules that seem to be better places for them.
generated by cgit v1.2.3 (git 2.25.1) at 2025-06-07 02:13:20 +0000