aboutsummaryrefslogtreecommitdiff
path: root/src/backend/parser
Commit message (Collapse)AuthorAge
...
* Fix failure to ensure that a snapshot is available to datatype input functionsTom Lane2008-12-13
| | | | | | | | | | | | | | | | | | | when they are invoked by the parser. We had been setting up a snapshot at plan time but really it needs to be done earlier, before parse analysis. Per report from Dmitry Koterov. Also fix two related problems discovered while poking at this one: exec_bind_message called datatype input functions without establishing a snapshot, and SET CONSTRAINTS IMMEDIATE could call trigger functions without establishing a snapshot. Backpatch to 8.2. The underlying problem goes much further back, but it is masked in 8.1 and before because we didn't attempt to invoke domain check constraints within datatype input. It would only be exposed if a C-language datatype input function used the snapshot; which evidently none do, or we'd have heard complaints sooner. Since this code has changed a lot over time, a back-patch is hardly risk-free, and so I'm disinclined to patch further than absolutely necessary.
* Allow CREATE OR REPLACE VIEW to add columns to the _end_ of the view.Bruce Momjian2008-12-06
| | | | Robert Haas
* Default values for function argumentsPeter Eisentraut2008-12-04
| | | | Pavel Stehule, with some tweaks by Peter Eisentraut
* Utilize the visibility map in autovacuum, too. There was an oversight inHeikki Linnakangas2008-12-04
| | | | | | | | | the visibility map patch that because autovacuum always sets VacuumStmt->freeze_min_age, visibility map was never used for autovacuum, only for manually launched vacuums. This patch introduces a new scan_all field to VacuumStmt, indicating explicitly whether the visibility map should be used, or the whole relation should be scanned, to advance relfrozenxid. Anti-wraparound vacuums still need to scan all pages.
* Add %expect 0 to all parser input files to prevent conflicts slipping by.Peter Eisentraut2008-11-26
|
* CLUSTER VERBOSE and corresponding clusterdb --verbose optionPeter Eisentraut2008-11-24
| | | | Jim Cox and Peter Eisentraut
* Use relation_expr for TABLE command, requested by Tom.Peter Eisentraut2008-11-21
|
* TABLE commandPeter Eisentraut2008-11-20
|
* Make SELECT FOR UPDATE/SHARE work on inheritance trees, by having the planTom Lane2008-11-15
| | | | | | | | | return the tableoid as well as the ctid for any FOR UPDATE targets that have child tables. All child tables are listed in the ExecRowMark list, but the executor just skips the ones that didn't produce the current row. Curiously, this longstanding restriction doesn't seem to have been documented anywhere; so no doc changes.
* Removed two non-terminals:Michael Meskes2008-11-13
| | | | | - FloatOnly: only used by NumericOnly, instead put the FloatOnly production into NumericOnly - IntegerOnly: only used by NumericOnly and one ALTER TABLE rule, replacement SignedIconst is already used in several other places
* Do not use ICONST/SCONST in rules other than Iconst/Sconst.Michael Meskes2008-11-12
|
* Implement ALTER DATABASE SET TABLESPACE to move a whole database (or at leastTom Lane2008-11-07
| | | | | | as much of it as lives in its default tablespace) to a new tablespace. Guillaume Lelarge, with some help from Bernd Helmle and Tom Lane
* Added missing ';'Michael Meskes2008-10-31
|
* Add support for user-defined I/O conversion casts.Heikki Linnakangas2008-10-31
|
* Since SQL:2003, the array size specification in the SQL ARRAY syntax hasPeter Eisentraut2008-10-29
| | | | been optional.
* Unicode escapes in strings and identifiersPeter Eisentraut2008-10-29
|
* Add WITH [NO] DATA clause to CREATE TABLE AS, per SQL.Peter Eisentraut2008-10-28
| | | | | | | Also, since WITH is now a reserved word, simplify the token merging code to only deal with WITH_TIME. by Tom Lane and myself
* SQL:2008 syntax CURRENT_CATALOG, CURRENT_SCHEMA, SET CATALOG, SET SCHEMA.Peter Eisentraut2008-10-27
|
* Allow EXPLAIN on CREATE TABLE AS.Peter Eisentraut2008-10-27
|
* Better solution to the IN-list issue: instead of having an arbitrary cutoff,Tom Lane2008-10-26
| | | | | | | treat Var and non-Var IN-list items differently. Only non-Var items are candidates to go into an ANY(ARRAY) construct --- we put all Vars as separate OR conditions on the grounds that that leaves more scope for optimization. Per suggestion from Robert Haas.
* Add a heuristic to transformAExprIn() to make it prefer expanding "x IN (list)"Tom Lane2008-10-25
| | | | | | | | | | | | | into an OR of equality comparisons, rather than x = ANY(ARRAY[...]), when there are Vars in the right-hand side. This avoids a performance regression compared to pre-8.2 releases, in cases where the OR form can be optimized into scans of multiple indexes. Limit the possible downside by preferring this form only when the list isn't very long (I set the cutoff at 32 elements, which is a bit arbitrary but in the right ballpark). Per discussion with Jim Nasby. In passing, also make it try the OR form if it cannot select a common type for the array elements; we've seen a complaint or two about how the OR form worked for such cases and ARRAY doesn't.
* SQL:2008 alternative syntax for LIMIT/OFFSET:Peter Eisentraut2008-10-22
| | | | OFFSET num {ROW|ROWS} FETCH {FIRST|NEXT} [num] {ROW|ROWS} ONLY
* Allow SQL:2008 syntax ALTER TABLE ... ALTER COLUMN ... SET DATA TYPEPeter Eisentraut2008-10-21
| | | | alongside our traditional syntax.
* SQL 200N -> SQL:2003Peter Eisentraut2008-10-20
|
* Implement comparison of generic records (composite types), and invent aTom Lane2008-10-13
| | | | | | | | | | | | | pseudo-type record[] to represent arrays of possibly-anonymous composite types. Since composite datums carry their own type identification, no extra knowledge is needed at the array level. The main reason for doing this right now is that it is necessary to support the general case of detection of cycles in recursive queries: if you need to compare more than one column to detect a cycle, you need to compare a ROW() to an array built from ROW()s, at least if you want to do it as the spec suggests. Add some documentation and regression tests concerning the cycle detection issue.
* Modify the parser's error reporting to include a specific hint for the caseTom Lane2008-10-08
| | | | | | | of referencing a WITH item that's not yet in scope according to the SQL spec's semantics. This seems to be an easy error to make, and the bare "relation doesn't exist" message doesn't lead one's mind in the correct direction to fix it.
* Extend CTE patch to support recursive UNION (ie, without ALL). TheTom Lane2008-10-07
| | | | | | implementation uses an in-memory hash table, so it will poop out for very large recursive results ... but the performance characteristics of a sort-based implementation would be pretty unpleasant too.
* Improve parser error location for cases where an INSERT or UPDATE commandTom Lane2008-10-07
| | | | | | | | | supplies an expression that can't be coerced to the target column type. The code previously attempted to point at the target column name, which doesn't work at all in an INSERT with omitted column name list, and is also not remarkably helpful when the problem is buried somewhere in a long INSERT-multi-VALUES command. Make it point at the failed expression instead.
* 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.
* Fix GetCTEForRTE() to deal with the possibility that the RTE it's given cameTom Lane2008-10-06
| | | | from a query level above the current ParseState.
* Fix the implicit-RTE code to be able to handle implicit RTEs for CTEs, asTom Lane2008-10-06
| | | | | | | | | | 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.
* Improve behavior of WITH RECURSIVE with an untyped literal in theTom Lane2008-10-05
| | | | non-recursive term. Per an example from Dickson S. Guedes.
* Fix markTargetListOrigin() to not fail on a simple-Var reference to aTom Lane2008-10-05
| | | | | | recursive CTE that we're still in progress of analyzing. Add a similar guard to the similar code in expandRecordVariable(), and tweak regression tests to cover this case. Per report from Dickson S. Guedes.
* 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
* Make LC_COLLATE and LC_CTYPE database-level settings. Collation andHeikki Linnakangas2008-09-23
| | | | | | | | ctype are now more like encoding, stored in new datcollate and datctype columns in pg_database. This is a stripped-down version of Radek Strnad's patch, with further changes by me.
* Adjust the parser to accept the typename syntax INTERVAL ... SECOND(n)Tom Lane2008-09-11
| | | | | | | | | | | | | | | | | | | and the literal syntax INTERVAL 'string' ... SECOND(n), as required by the SQL standard. Our old syntax put (n) directly after INTERVAL, which was a mistake, but will still be accepted for backward compatibility as well as symmetry with the TIMESTAMP cases. Change intervaltypmodout to show it in the spec's way, too. (This could potentially affect clients, if there are any that analyze the typmod of an INTERVAL in any detail.) Also fix interval input to handle 'min:sec.frac' properly; I had overlooked this case in my previous patch. Document the use of the interval fields qualifier, which up to now we had never mentioned in the docs. (I think the omission was intentional because it didn't work per spec; but it does now, or at least close enough to be credible.)
* Make our parsing of INTERVAL literals spec-compliant (or at least a heck ofTom Lane2008-09-10
| | | | | | | | | | | | | | | a lot closer than it was before). To do this, tweak coerce_type() to pass through the typmod information when invoking interval_in() on an UNKNOWN constant; then fix DecodeInterval to pay attention to the typmod when deciding how to interpret a units-less integer value. I changed one or two other details as well. I believe the code now reacts as expected by spec for all the literal syntaxes that are specifically enumerated in the spec. There are corner cases involving strings that don't exactly match the set of fields called out by the typmod, for which we might want to tweak the behavior some more; but I think this is an area of user friendliness rather than spec compliance. There remain some non-compliant details about the SQL syntax (as opposed to what's inside the literal string); but at least we'll throw error rather than silently doing the wrong thing in those cases.
* Improve the plan cache invalidation mechanism to make it invalidate plansTom Lane2008-09-09
| | | | | | | | | when user-defined functions used in a plan are modified. Also invalidate plans when schemas, operators, or operator classes are modified; but for these cases we just invalidate everything rather than tracking exact dependencies, since these types of objects seldom change in a production database. Tom Lane; loosely based on a patch by Martin Pihlak.
* Prevent memory leaks in our various bison parsers when an error occursTom Lane2008-09-02
| | | | | | | during parsing. Formerly the parser's stack was allocated with malloc and so wouldn't be reclaimed; this patch makes it use palloc instead, so that flushing the current context will reclaim the memory. Per Marko Kreen.
* 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.
* Fix the raw-parsetree representation of star (as in SELECT * FROM orTom Lane2008-08-30
| | | | | | 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.
* Remove all traces that suggest that a non-Bison yacc might be supported, andPeter Eisentraut2008-08-29
| | | | | change build system to use only Bison. Simplify build rules, make file names uniform. Don't build the token table header file where it is not needed.
* Extend the parser location infrastructure to include a location field inTom Lane2008-08-28
| | | | | | | | | | | | | 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-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.
* Teach the system how to use hashing for UNION. (INTERSECT/EXCEPT will follow,Tom Lane2008-08-07
| | | | | | | | | | | 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-05
| | | | | | | | | | | | | | | | | | | 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-03
| | | | | | 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-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.
* Fix parser so that we don't modify the user-written ORDER BY list in orderTom Lane2008-07-31
| | | | | | | | | | 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.
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-04 09:23:11 +0000