summaryrefslogtreecommitdiff
path: root/src/backend/parser/parse_clause.c
Commit message (Collapse)AuthorAgeFilesLines
* Remove tabs after spaces in C commentsBruce Momjian2014-05-061-14/+14
| | | | | | | | | This was not changed in HEAD, but will be done later as part of a pgindent run. Future pgindent runs will also do this. Report by Tom Lane Backpatch through all supported branches, but not HEAD
* Improve the error message given for modifying a window with frame clause.Tom Lane2013-11-051-5/+26
| | | | | | | | | | | | | | For rather inscrutable reasons, SQL:2008 disallows copying-and-modifying a window definition that has any explicit framing clause. The error message we gave for this only made sense if the referencing window definition itself contains an explicit framing clause, which it might well not. Moreover, in the context of an OVER clause it's not exactly obvious that "OVER (windowname)" implies copy-and-modify while "OVER windowname" does not. This has led to multiple complaints, eg bug #5199 from Iliya Krapchatov. Change to a hopefully more intelligible error message, and in the case where we have just "OVER (windowname)", add a HINT suggesting that omitting the parentheses will fix it. Also improve the related documentation. Back-patch to all supported branches.
* Make FOR UPDATE/SHARE in the primary query not propagate into WITH queries;Tom Lane2009-10-271-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | for example in WITH w AS (SELECT * FROM foo) SELECT * FROM w, bar ... FOR UPDATE the FOR UPDATE will now affect bar but not foo. This is more useful and consistent than the original 8.4 behavior, which tried to propagate FOR UPDATE into the WITH query but always failed due to assorted implementation restrictions. Even though we are in process of removing those restrictions, it seems correct on philosophical grounds to not let the outer query's FOR UPDATE affect the WITH query. In passing, fix isLockedRel which frequently got things wrong in nested-subquery cases: "FOR UPDATE OF foo" applies to an alias foo in the current query level, not subqueries. This has been broken for a long time, but it doesn't seem worth back-patching further than 8.4 because the actual consequences are minimal. At worst the parser would sometimes get RowShareLock on a relation when it should be AccessShareLock or vice versa. That would only make a difference if someone were using ExclusiveLock concurrently, which no standard operation does, and anyway FOR UPDATE doesn't result in visible changes so it's not clear that the someone would notice any problem. Between that and the fact that FOR UPDATE barely works with subqueries at all in existing releases, I'm not excited about worrying about it.
* Fix bug with WITH RECURSIVE immediately inside WITH RECURSIVE. 99% of theTom Lane2009-09-091-2/+2
| | | | | | | | | | | code was already okay with this, but the hack that obtained the output column types of a recursive union in advance of doing real parse analysis of the recursive union forgot to handle the case where there was an inner WITH clause available to the non-recursive term. Best fix seems to be to refactor so that we don't need the "throwaway" parse analysis step at all. Instead, teach the transformSetOperationStmt code to set up the CTE's output column information after it's processed the non-recursive term normally. Per report from David Fetter.
* Modify the definition of window-function PARTITION BY and ORDER BY clausesTom Lane2009-08-271-40/+81
| | | | | | | | | | | | | | | | | | | so that their elements are always taken as simple expressions over the query's input columns. It originally seemed like a good idea to make them act exactly like GROUP BY and ORDER BY, right down to the SQL92-era behavior of accepting output column names or numbers. However, that was not such a great idea, for two reasons: 1. It permits circular references, as exhibited in bug #5018: the output column could be the one containing the window function itself. (We actually had a regression test case illustrating this, but nobody thought twice about how confusing that would be.) 2. It doesn't seem like a good idea for, eg, "lead(foo) OVER (ORDER BY foo)" to potentially use two completely different meanings for "foo". Accordingly, narrow down the behavior of window clauses to use only the SQL99-compliant interpretation that the expressions are simple expressions.
* 8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef listBruce Momjian2009-06-111-64/+64
| | | | provided by Andrew.
* Remove the recently added node types ReloptElem and OptionDefElem in favorTom Lane2009-04-041-5/+6
| | | | | | of adding optional namespace and action fields to DefElem. Having three node types that do essentially the same thing bloats the code and leads to errors of confusion, such as in yesterday's bug report from Khee Chin.
* Allow reloption names to have qualifiers, initially supporting a TOASTAlvaro Herrera2009-02-021-5/+5
| | | | | | | | qualifier, and add support for this in pg_dump. This allows TOAST tables to have user-defined fillfactor, and will also enable us to move the autovacuum parameters to reloptions without taking away the possibility of setting values for TOAST tables.
* Support column-level privileges, as required by SQL standard.Tom Lane2009-01-221-6/+25
| | | | Stephen Frost, with help from KaiGai Kohei and others
* Update copyright for 2009.Bruce Momjian2009-01-011-2/+2
|
* Throw error if a <window definition> references a window that already has aTom Lane2008-12-311-2/+11
| | | | | frame clause, as appears to be required by the fine print in the SQL spec. Per discussion with Pavel, not doing so risks user confusion.
* Add some basic support for window frame clauses to the window-functionsTom Lane2008-12-311-2/+3
| | | | | | | | 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-281-17/+186
| | | | Hitoshi Harada, with some kibitzing from Heikki and Tom.
* Fix the implicit-RTE code to be able to handle implicit RTEs for CTEs, asTom Lane2008-10-061-25/+6
| | | | | | | | | | well as regular tables. Per discussion, this seems necessary to meet the principle of least astonishment. In passing, simplify the error messages in warnAutoRange(). Now that we have parser error position info for these errors, it doesn't seem very useful to word the error message differently depending on whether we are inside a sub-select or not.
* Implement SQL-standard WITH clauses, including WITH RECURSIVE.Tom Lane2008-10-041-4/+54
| | | | | | | | | | | | | 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
* Add a bunch of new error location reports to parse-analysis error messages.Tom Lane2008-09-011-54/+134
| | | | | There are still some weak spots around JOIN USING and relation alias lists, but most errors reported within backend/parser/ now have locations.
* Fix the raw-parsetree representation of star (as in SELECT * FROM orTom Lane2008-08-301-2/+3
| | | | | | SELECT foo.*) so that it cannot be confused with a quoted identifier "*". Instead create a separate node type A_Star to represent this notation. Per pgsql-hackers discussion of 2007-Sep-27.
* Extend the parser location infrastructure to include a location field inTom Lane2008-08-281-10/+18
| | | | | | | | | | | | | most node types used in expression trees (both before and after parse analysis). This allows us to place an error cursor in many situations where we formerly could not, because the information wasn't available beyond the very first level of parse analysis. There's a fair amount of work still to be done to persuade individual ereport() calls to actually include an error location, but this gets the initdb-forcing part of the work out of the way; and the situation is already markedly better than before for complaints about unimplementable implicit casts, such as CASE and UNION constructs with incompatible alternative data types. Per my proposal of a few days ago.
* Move exprType(), exprTypmod(), expression_tree_walker(), and related routinesTom Lane2008-08-251-2/+2
| | | | | | 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.
* Teach the system how to use hashing for UNION. (INTERSECT/EXCEPT will follow,Tom Lane2008-08-071-11/+10
| | | | | | | | | | | but seem like a separate patch since most of the remaining work is on the executor side.) I took the opportunity to push selection of the grouping operators for set operations into the parser where it belongs. Otherwise this is just a small exercise in making prepunion.c consider both alternatives. As with the recent DISTINCT patch, this means we can UNION on datatypes that can hash but not sort, and it means that UNION without ORDER BY is no longer certain to produce sorted output.
* Improve SELECT DISTINCT to consider hash aggregation, as well as sort/uniq,Tom Lane2008-08-051-8/+3
| | | | | | | | | | | | | | | | | | | as methods for implementing the DISTINCT step. This eliminates the former performance gap between DISTINCT and GROUP BY, and also makes it possible to do SELECT DISTINCT on datatypes that only support hashing not sorting. SELECT DISTINCT ON is still always implemented by sorting; it would take executor changes to support hashing that, and it's not clear it's worth the trouble. This is a release-note-worthy incompatibility from previous PG versions, since SELECT DISTINCT can no longer be counted on to deliver sorted output without explicitly saying ORDER BY. (Anyone who can't cope with that can consider turning off enable_hashagg.) Several regression test queries needed to have ORDER BY added to preserve stable output order. I fixed the ones that manifested here, but there might be some other cases that show up on other platforms.
* Make GROUP BY work properly for datatypes that only support hashing and notTom Lane2008-08-031-6/+2
| | | | | | sorting. The infrastructure for this was all in place already; it's only necessary to fix the planner to not assume that sorting is always an available option.
* Rearrange the querytree representation of ORDER BY/GROUP BY/DISTINCT itemsTom Lane2008-08-021-235/+262
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Fix parser so that we don't modify the user-written ORDER BY list in orderTom Lane2008-07-311-97/+102
| | | | | | | | | | to represent DISTINCT or DISTINCT ON. This gets rid of a longstanding annoyance that a view or rule using SELECT DISTINCT will be dumped out with an overspecified ORDER BY list, and is one small step along the way to decoupling DISTINCT and ORDER BY enough so that hash-based implementation of DISTINCT will be possible. In passing, improve transformDistinctClause so that it doesn't reject duplicate DISTINCT ON items, as was reported by Steve Midgley a couple weeks ago.
* Improve our #include situation by moving pointer types away from theAlvaro Herrera2008-06-191-1/+2
| | | | | | | corresponding struct definitions. This allows other headers to avoid including certain highly-loaded headers such as rel.h and relscan.h, instead using just relcache.h, heapam.h or genam.h, which are more lightweight and thus cause less unnecessary dependencies.
* Remove ancient restriction that LIMIT/OFFSET can't contain a sub-select.Tom Lane2008-02-151-12/+2
| | | | | | | This was probably protecting some implementation limitation when it was put in, but as far as I can tell the planner and executor have no such assumption anymore; the case seems to work fine. Per a gripe from Grzegorz Jaskiewicz.
* Update copyrights in source tree to 2008.Bruce Momjian2008-01-011-2/+2
|
* pgindent run for 8.3.Bruce Momjian2007-11-151-8/+9
|
* Separate parse-analysis for utility commands out of parser/analyze.cTom Lane2007-06-231-15/+7
| | | | | | | | | | | | | | | | | (which now deals only in optimizable statements), and put that code into a new file parser/parse_utilcmd.c. This helps clarify and enforce the design rule that utility statements shouldn't be processed during the regular parse analysis phase; all interpretation of their meaning should happen after they are given to ProcessUtility to execute. (We need this because we don't retain any locks for a utility statement that's in a plan cache, nor have any way to detect that it's stale.) We are also able to simplify the API for parse_analyze() and related routines, because they will now always return exactly one Query structure. In passing, fix bug #3403 concerning trying to add a serial column to an existing temp table (this is largely Heikki's work, but we needed all that restructuring to make it safe).
* Modify processing of DECLARE CURSOR and EXPLAIN so that they can resolve theTom Lane2007-04-271-3/+4
| | | | | | | | | | | | | | types of unspecified parameters when submitted via extended query protocol. This worked in 8.2 but I had broken it during plancache changes. DECLARE CURSOR is now treated almost exactly like a plain SELECT through parse analysis, rewrite, and planning; only just before sending to the executor do we divert it away to ProcessUtility. This requires a special-case check in a number of places, but practically all of them were already special-casing SELECT INTO, so it's not too ugly. (Maybe it would be a good idea to merge the two by treating IntoClause as a form of utility statement? Not going to worry about that now, though.) That approach doesn't work for EXPLAIN, however, so for that I punted and used a klugy solution of running parse analysis an extra time if under extended query protocol.
* Wording cleanup for error messages. Also change can't -> cannot.Bruce Momjian2007-02-011-4/+4
| | | | | | | | | | | | | | Standard English uses "may", "can", and "might" in different ways: may - permission, "You may borrow my rake." can - ability, "I can lift that log." might - possibility, "It might rain today." Unfortunately, in conversational English, their use is often mixed, as in, "You may use this variable to do X", when in fact, "can" is a better choice. Similarly, "It may crash" is better stated, "It might crash".
* Change the planner-to-executor API so that the planner tells the executorTom Lane2007-01-101-2/+3
| | | | | | | | | | | | | | | | which comparison operators to use for plan nodes involving tuple comparison (Agg, Group, Unique, SetOp). Formerly the executor looked up the default equality operator for the datatype, which was really pretty shaky, since it's possible that the data being fed to the node is sorted according to some nondefault operator class that could have an incompatible idea of equality. The planner knows what it has sorted by and therefore can provide the right equality operator to use. Also, this change moves a couple of catalog lookups out of the executor and into the planner, which should help startup time for pre-planned queries by some small amount. Modify the planner to remove some other cavalier assumptions about always being able to use the default operators. Also add "nulls first/last" info to the Plan node for a mergejoin --- neither the executor nor the planner can cope yet, but at least the API is in place.
* Support ORDER BY ... NULLS FIRST/LAST, and add ASC/DESC/NULLS FIRST/NULLS LASTTom Lane2007-01-091-41/+107
| | | | | | | | | | | | per-column options for btree indexes. The planner's support for this is still pretty rudimentary; it does not yet know how to plan mergejoins with nondefault ordering options. The documentation is pretty rudimentary, too. I'll work on improving that stuff later. Note incompatible change from prior behavior: ORDER BY ... USING will now be rejected if the operator is not a less-than or greater-than member of some btree opclass. This prevents less-than-sane behavior if an operator that doesn't actually define a proper sort ordering is selected.
* Update CVS HEAD for 2007 copyright. Back branches are typically notBruce Momjian2007-01-051-2/+2
| | | | back-stamped for this.
* Code review for XML patch. Instill a bit of sanity in the location ofTom Lane2006-12-241-2/+2
| | | | | | | the XmlExpr code in various lists, use a representation that has some hope of reverse-listing correctly (though it's still a de-escaping function shy of correctness), generally try to make it look more like Postgres coding conventions.
* Fix some translator comments so that xgettext finds them and pgindent doesPeter Eisentraut2006-11-281-5/+3
| | | | not destroy them. Maybe we can adjust pgindent sometime.
* pgindent run for 8.2.Bruce Momjian2006-10-041-22/+21
|
* Cause '*' and 'foo.*' notations to mark the referenced RTE(s) asTom Lane2006-08-141-3/+4
| | | | | | | | | requiring read permissions. Up till now there was no possible case in which the RTEs wouldn't already have ACL_SELECT set ... but now that you can say something like 'INSERT INTO foo ... RETURNING *' this is an essential step. With this commit, a RETURNING clause adds the requirement for SELECT permissions on the target table if and only if the clause actually reads the value of at least one target-table column.
* Tweak SPI_cursor_open to allow INSERT/UPDATE/DELETE RETURNING; this wasTom Lane2006-08-121-2/+2
| | | | | | | | merely a matter of fixing the error check, since the underlying Portal infrastructure already handles it. This in turn allows these statements to be used in some existing plpgsql and plperl contexts, such as a plpgsql FOR loop. Also, do some marginal code cleanup in places that were being sloppy about distinguishing SELECT from SELECT INTO.
* Code review for bigint-LIMIT patch. Fix missed planner dependency,Tom Lane2006-07-261-3/+6
| | | | | | eliminate unnecessary code, force initdb because stored rules change (limit nodes are now supposed to be int8 not int4 expressions). Update comments and error messages, which still all said 'integer'.
* Change LIMIT/OFFSET to use int8Bruce Momjian2006-07-261-2/+2
| | | | Dhanaraj M
* Remove 576 references of include files that were not needed.Bruce Momjian2006-07-141-3/+1
|
* Allow include files to compile own their own.Bruce Momjian2006-07-131-1/+2
| | | | | | | Strip unused include files out unused include files, and add needed includes to C files. The next step is to remove unused include files in C files.
* Code review for FILLFACTOR patch. Change WITH grammar as per earlierTom Lane2006-07-031-265/+9
| | | | | | | | | | | | | | | | discussion (including making def_arg allow reserved words), add missed opt_definition for UNIQUE case. Put the reloptions support code in a less random place (I chose to make a new file access/common/reloptions.c). Eliminate header inclusion creep. Make the index options functions safely user-callable (seems like client apps might like to be able to test validity of options before trying to make an index). Reduce overhead for normal case with no options by allowing rd_options to be NULL. Fix some unmaintainably klugy code, including getting rid of Natts_pg_class_fixed at long last. Some stylistic cleanup too, and pay attention to keeping comments in sync with code. Documentation still needs work, though I did fix the omissions in catalogs.sgml and indexam.sgml.
* Add FILLFACTOR to CREATE INDEX.Bruce Momjian2006-07-021-12/+267
| | | | ITAGAKI Takahiro
* Clean up representation of function RTEs for functions returning RECORD.Tom Lane2006-03-161-10/+14
| | | | | | | | | | | | | | | | The original coding stored the raw parser output (ColumnDef and TypeName nodes) which was ugly, bulky, and wrong because it failed to create any dependency on the referenced datatype --- and in fact would not track type renamings and suchlike. Instead store a list of column type OIDs in the RTE. Also fix up general failure of recordDependencyOnExpr to do anything sane about recording dependencies on datatypes. While there are many cases where there will be an indirect dependency (eg if an operator returns a datatype, the dependency on the operator is enough), we do have to record the datatype as a separate dependency in examples like CoerceToDomain. initdb forced because of change of stored rules.
* Improve parser so that we can show an error cursor position for errorsTom Lane2006-03-141-5/+9
| | | | | | | | | | | during parse analysis, not only errors detected in the flex/bison stages. This is per my earlier proposal. This commit includes all the basic infrastructure, but locations are only tracked and reported for errors involving column references, function calls, and operators. More could be done later but this seems like a good set to start with. I've also moved the ReportSyntaxErrorPosition logic out of psql and into libpq, which should make it available to more people --- even within psql this is an improvement because warnings weren't handled by ReportSyntaxErrorPosition.
* Per recent discussion on -hackers, we should sometimes reorder theNeil Conway2006-03-051-41/+85
| | | | | | | | | | columns of the grouping clause to avoid redundant sorts. The optimizer is not currently capable of doing this, so this patch implements a simple hack in the analysis phase (transformGroupClause): if any subset of the GROUP BY clause matches a prefix of the ORDER BY list, that prefix is moved to the front of the GROUP BY clause. This shouldn't change the semantics of the query, and allows a redundant sort to be avoided for queries like "GROUP BY a, b ORDER BY b".
* Update copyright for 2006. Update scripts.Bruce Momjian2006-03-051-2/+2
|
* Allow an optional alias for the target table to be specified for UPDATENeil Conway2006-01-221-2/+2
| | | | | | | | | | and DELETE. If specified, the alias must be used instead of the full table name. Also, the alias currently cannot be used in the SET clause of UPDATE. Patch from Atsushi Ogawa, various editorialization by Neil Conway. Along the way, make the rowtypes regression test pass if add_missing_from is enabled, and add a new (skeletal) regression test for DELETE.
View Lorry Controller Status