| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
In the backend, I changed only a handful of exemplary or important-looking
instances to make use of the plural support; there is probably more work
there. For the rest of the source, this should cover all relevant cases.
|
| |
|
|
|
|
|
|
|
| |
kwlist.h, to avoid having to link the backend object file into other programs
like pg_dump. We can now simply symlink a single source file from the backend
(kwlookup.c, containing the shared routine ScanKeywordLookup) and compile it
locally, which is a lot cleaner.
|
|
|
|
|
| |
"syntax error", not the literal string. I was previously confused on this
matter, but I have now verified that everything is translated properly.
|
|
|
|
|
|
| |
wrappers (similar to procedural languages). This way we don't need to retain
the nearly empty libraries, and we are more free in how to implement the
wrapper API in the future.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
get rid of the OID column. This eliminates the problem discovered by Heikki
back in November that 8.4's suppression of "unnecessary" junk filtering in
INSERT/SELECT could lead to an Assert failure, or storing of oids into a table
that shouldn't have them if Asserts are off. While that particular problem
could have been solved in other ways, it seems likely to be just a forerunner
of things to come if we continue to allow tables to contain rows that disagree
with the pg_class.relhasoids setting. It's better to make this operation slow
than to sacrifice performance or risk bugs in more common code paths.
Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids.
This was a bit more controversial, but in view of the very small amount of
extra code needed given the current ALTER TABLE infrastructure, it seems best
to eliminate the asymmetry in features.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Stephen Frost, with help from KaiGai Kohei and others
|
|
|
|
|
| |
ignore the visibility map and scan the whole table, to advance
relfrozenxid.
|
|
|
|
|
|
|
|
| |
business with inheritance recursion: ALTER INDEX, ALTER SEQUENCE, ALTER
TRIGGER, ALTER VIEW. They would just silently ignore the ONLY.
ALTER TABLE has mixed behavior and cannot be dealt with this way because
of the resulting shift/reduce conflicts.
|
|
|
|
|
|
| |
recursive.
=> Note this incompatibility in the release notes.
|
|
|
|
| |
from Rushabh Lathia.
|
|
|
|
| |
with URL pointing to email discussion.
|
| |
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Hitoshi Harada, with some kibitzing from Heikki and Tom.
|
| |
|
|
|
|
|
|
|
|
| |
This doesn't do any remote or external things yet, but it gives modules
like plproxy and dblink a standardized and future-proof system for
managing their connection information.
Martin Pihlak and Peter Eisentraut
|
|
|
|
|
| |
per recent discussions. In passing this also fixes a couple of bugs in
the previous variadic-parameters patch.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
skipped. We could update relpages anyway, but it seems better to only
update it together with reltuples, because we use the reltuples/relpages
ratio in the planner. Also don't update n_live_tuples in pgstat.
ANALYZE in VACUUM ANALYZE now needs to update pg_class, if the
VACUUM-phase didn't do so. Added some boolean-passing to let analyze_rel
know if it should update pg_class or not.
I also moved the relcache invalidation (to update rd_targblock) from
vac_update_relstats to where RelationTruncate is called, because
vac_update_relstats is not called for partial vacuums anymore. It's more
obvious to send the invalidation close to the truncation that requires it.
Per report by Ned T. Crigler.
|
|
|
|
|
|
|
| |
actual argument type of ANYARRAY to match an argument declared ANYARRAY,
so long as ANYELEMENT etc aren't used. I had overlooked the fact that this
is a possible case while fixing bug #3852; but it is possible because
pg_statistic contains columns declared ANYARRAY. Per gripe from Corey Horton.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Robert Haas
|
|
|
|
| |
Pavel Stehule, with some tweaks by Peter Eisentraut
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Jim Cox and Peter Eisentraut
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
- 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
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
| |
been optional.
|
| |
|
|
|
|
|
|
|
| |
Also, since WITH is now a reserved word, simplify the token merging code to
only deal with WITH_TIME.
by Tom Lane and myself
|
| |
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
OFFSET num {ROW|ROWS} FETCH {FIRST|NEXT} [num] {ROW|ROWS} ONLY
|
|
|
|
| |
alongside our traditional syntax.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|