| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
Per Tom's comment.
Also revome useless GISTScanOpaque->flags field.
|
|
|
|
| |
supported, to the extent that LOBs, arrays, and multisets are supported.
|
| |
|
| |
|
| |
|
|
|
|
| |
(I'm leaving GiST/GIN cleanup to Teodor.)
|
|
|
|
| |
formatted_start_time.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
scanning; GiST and GIN do not, and it seems like too much trouble to make
them do so. By teaching ExecSupportsBackwardScan() about this restriction,
we ensure that the planner will protect a scroll cursor from the problem
by adding a Materialize node.
In passing, fix another longstanding bug in the same area: backwards scan of
a plan with set-returning functions in the targetlist did not work either,
since the TupFromTlist expansion code pays no attention to direction (and
has no way to run a SRF backwards anyway). Again the fix is to make
ExecSupportsBackwardScan check this restriction.
Also adjust the index AM API specification to note that mark/restore support
is unnecessary if the AM can't produce ordered output.
|
|
|
|
|
|
|
| |
set_rel_width(). The code had been catering for the possibility of different
varnos in the relation targetlist, but this is impossible for a base relation
(and if it were possible, putting all the widths in the same RelOptInfo would
be wrong anyway).
|
|
|
|
|
|
| |
several fragments a-la Google.
Sushant Sinha <sushant354@gmail.com>
|
|
|
|
|
| |
Patch from Sushant Sinha <sushant354@gmail.com>
http://archives.postgresql.org/pgsql-hackers/2008-07/msg00785.php
|
|
|
|
|
|
|
|
|
| |
is NULL but SK_SEARCHNULL is not set. Add checking IS NULL of keys
to set during key initialization. If key is NULL and SK_SEARCHNULL is not
set then nothnig can be satisfied.
With assert-enabled compilation that causes coredump.
Bug was introduced in 8.3 by support of IS NULL index scan.
|
|
|
|
|
|
|
| |
In the previous coding, the list of columns that needed to be hashed on
was allocated in the per-query context, but we reallocated every time
the Agg node was rescanned. Since this information doesn't change over
a rescan, just construct the list of columns once during ExecInitAgg().
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
according to the TupleDesc's natts, not the number of physical columns in the
tuple. The previous coding would do the wrong thing in cases where natts is
different from the tuple's column count: either incorrectly report error when
it should just treat the column as null, or actually crash due to indexing off
the end of the TupleDesc's attribute array. (The second case is probably not
possible in modern PG versions, due to more careful handling of inheritance
cases than we once had. But it's still a clear lack of robustness here.)
The incorrect error indication is ignored by all callers within the core PG
distribution, so this bug has no symptoms visible within the core code, but
it might well be an issue for add-on packages. So patch all the way back.
|
|
|
|
|
|
| |
lengthof(SysAtt) not FirstLowInvalidHeapAttributeNumber, for consistency with
the other uses of the SysAtt array, and to make it clearer that it doesn't
walk off the end of that array.
|
|
|
|
|
|
|
| |
Formerly, the lack of any opclasses that could accept such data was enough
of a defense, but now with a "record" opclass we need to check more carefully.
(You can still use that opclass for an index, but you have to store a named
composite type not an anonymous one.)
|
|
|
|
| |
by renaming the new copies after the catalog games.
|
|
|
|
|
|
|
| |
the timestamp types. Turns out this doesn't even reduce the available
range of dates, since the restriction to dates that work for Julian-date
arithmetic is much tighter than the int32 range anyway. Per a longstanding
TODO item.
|
|
|
|
| |
returning a failure code that none of its callers bothered to check for.
|
|
|
|
|
| |
fsync requests. This should fix the installcheck failure of the buildfarm
member "kudu".
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
RecursiveUnion to which it refers. It turns out that we can just postpone the
relevant initialization steps until the first exec call for the node, by which
time the ancestor node must surely be initialized. Per report from Greg Stark.
|
|
|
|
| |
for bitmap index scans. Per report and test case from Kevin Grittner.
|
|
|
|
|
| |
Depesz Lubaczewski. In HEAD, also move a couple of other cases to make the
code ordering match up with ProcessUtility.
|
|
|
|
|
| |
it can handle functions returning setof record. The case was left undone
originally, but it turns out to be simple to fix.
|
|
|
|
|
| |
the ereport macro. Included in this commit are enough files for starting
plpgsql, plpython, plperl and pltcl translations.
|
|
|
|
|
| |
Report and fix by Michael McMaster. Some minor code beautification by me,
also avoid memory leaks in the special-case paths.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to process any pending unlinks for the source database.
Before, if you dropped a relation in the template database just before
CREATE DATABASE, and a checkpoint happened during copydir(), the checkpoint
might delete a file that we're just about to copy, causing lstat() in
copydir() to fail with ENOENT.
Backpatch to 8.3, where the pending unlinks were introduced.
Per report by Matthew Wakeling and analysis by Tom Lane.
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
use the old relfilenode in the new tablespace. There might be another relation
in the new tablespace with the same relfilenode, so we must generate a fresh
relfilenode in the new tablespace.
The 8.3 patch to let deleted relation files linger as zero-length files until
the next checkpoint made this more obvious: moving a relation from one table
space another, and then back again, caused a collision with the lingering
file.
Back-patch to 8.1. The issue is present in 8.0 as well, but it doesn't seem
worth fixing there, because we didn't have protection from OID collisions
after OID wraparound before 8.1.
Report by Guillaume Lelarge.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
tuplestore: in READFILE state tuplestore_select_read_pointer must
save the current file seek position in the read pointer being
deactivated.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
from a query level above the current ParseState.
|
|
|
|
|
|
| |
relation forks. While the file names are not visible to users, for those
that do peek into the data directory, it's nice to have more descriptive
names. Per Greg Stark's suggestion.
|
|
|
|
|
|
|
| |
the value a parameter has at server start and will have after RESET,
respectively.
Greg Smith, with some modifications by me.
|
| |
|
|
|
|
| |
maybe isalnum is returning a value with the low-order byte all zero?
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
machine produces zero (rather than the more usual minimum-possible-integer)
for the only possible overflow case. This has been seen to occur for at least
some word widths on some hardware, and it's cheap enough to check for
everywhere. Per Peter's analysis of buildfarm reports.
This could be back-patched, but in the absence of any gripes from the field
I doubt it's worth the trouble.
|
|
|
|
| |
non-recursive term. Per an example from Dickson S. Guedes.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
nullvalue, nonvalue. A long time ago, these were used to implement the SQL
constructs IS TRUE, etc.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
name of a fork ('main' or 'fsm', at the moment) to pg_relation_size() to
get the size of a specific fork. Defaults to 'main', if none given.
While we're at it, modify pg_relation_size to take a regclass as argument,
instead of separate variants taking oid and name. This change is
transparent to typical use where the table name is passed as a string
literal, like pg_relation_size('table'), but will break queries like
pg_relation_size(namecol), where namecol is of type name. text-type input
still works, and using a non-schema-qualified table name is not very
reliable anyway, so this is unlikely to break anyone's queries in practice.
|
|
|
|
| |
code in 8.4.
|
|
|
|
|
|
| |
when using --enable-integer-datetimes and a non-ISO datestyle.
Ron Mayer
|