| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
versions won't compile it at all with those there. Probably of only
academic interest now, but ...
|
|
|
|
| |
(That's what I get for not testing the back branches *before* committing.)
|
|
|
|
|
|
| |
was large enough to be batched and the tuples fell into a batch where
there were no inner tuples at all. Thanks to Xiaoyu Wang for finding a
test case that exposed this long-standing bug.
|
|
|
|
|
|
| |
easily exhaust memory on databases with more than a few hundred triggers.
I don't expect any more releases of these old versions, but let's put the
fix in CVS just so it's archived.
|
|
|
|
| |
Tid scan has been broken for 7.1.
|
| |
|
|
|
|
|
|
|
| |
returns the first result in the DB-API compliant wrapper. It turned out
that the bug was way down in the C code.
Gerhard Häring
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
not a plain relation).
|
| |
|
| |
|
|
|
|
| |
on views.
|
|
|
|
|
|
|
| |
has a DISTINCT ON clause, per bug report from Anthony Wood. While at it,
improve the DISTINCT-ON-clause recognizer routine to not be fooled by out-
of-order DISTINCT lists.
Also, back-patch earlier fix to not push down into sub-SELECT with LIMIT.
|
|
|
|
|
| |
namely after the view definition rather than before it. Bug introduced
in 7.1 by changes to dump stuff in OID ordering.
|
| |
|
|
|
|
|
| |
after writing/unpinning it. An actual failure is unlikely, unless the
system is tremendously short of buffers ... but a bug is a bug.
|
|
|
|
|
| |
(it's a field of a tuple). I see Jan has already fixed this in
current sources, but 7.1.* is pretty badly broken here.
|
|
|
|
|
|
| |
manipulation of rtable/jointree by planner. Rewriter was generating
actions that shared rtable/jointree substructure, which caused havoc
when planner got to the later actions that it'd already mucked up.
|
| |
|
|
|
|
|
|
| |
because cached fmgr info contained reference to a shorter-lived data
structure. Also guard against possibility that fmgr_info could fail,
leaving an incomplete entry present in the hash table.
|
| |
|
|
|
|
|
|
| |
Without patch, the time zone field is ignored and the returned time is
not correct.
Already applied to the development tree...
|
|
|
|
|
| |
initdb to fix this in 7.1 installations, but it seems better to be
shipping a correct entry than a wrong one.
|
|
|
|
| |
the buffer lock while checking page free space).
|
| |
|
|
|
|
|
|
|
|
| |
trees (mostly my fault). Repair. Also fix long-standing bug in ExecReplace:
after recomputing a concurrently updated tuple, we must recheck constraints.
Make EvalPlanQual leak memory with somewhat less enthusiasm than before,
although plugging leaks fully will require more changes than I care to risk
in a dot-release.
|
|
|
|
|
| |
for relations on the nullable side of an OUTER JOIN. For now I think
we'd better refuse such queries.
|
| |
|
|
|
|
|
|
| |
not TRUE. Otherwise we break pl call handler functions. fmgr_oldstyle
will take care of making sure the semantics are the same for C functions.
Clean up some slightly grotty coding in 7.0 pg_class reading, also.
|
| |
|
|
|
|
|
|
|
|
|
| |
- Fix view dumping SQL for V7.0
- Fix bug when getting view oid with long view names
- Treat SEQUENCE SET TOC entries as data entries rather than schema
entries.
- Make allowance for data entries that did not have a data dumper
routine (eg. SEQUENCE SET)
|
| |
|
|
|
|
| |
set null/default).
|
|
|
|
|
|
|
|
|
| |
to their children, leading to misbehavior if they had any children that paid
attention to chgParam (most plan node types don't). Append's bug has been
there a long time, but nobody had noticed because it used to be difficult
to create a query where an Append would be used below the top level of a
plan; so there were never any parameters getting passed down. SubqueryScan
is new in 7.1 ... and I'd modeled its behavior on Append :-(
|
|
|
|
|
| |
passed, which occurs when no rows are retrieved by a SELECT.
Mea maxima culpa ... I should have caught this.
|
| |
|
|
|
|
| |
going to have any at all.
|
|
|
|
|
| |
running deferred triggers. They are really part of the regular
transaction, and they could take awhile.
|
|
|
|
|
|
|
|
|
| |
routine DetermineLocalTimeZone(). In that routine, be more wary of
broken mktime() implementations than the original code was: don't allow
mktime to change the already-set y/m/d/h/m/s information, and don't
use tm_gmtoff if mktime failed. Possibly this will resolve some of
the complaints we've been hearing from users of Middle Eastern timezones
on RedHat.
|
|
|
|
|
|
|
| |
support two - KOI8-R and KOI8-U (latter is superset of the former if
not to take to the account pseudographics)
Andy Rysin
|
|
|
|
| |
either :-(.
|
|
|
|
| |
Oleg Bartunov
|
|
|
|
|
|
|
|
|
|
| |
give consistent results for all datatypes. Types float4, float8, and
numeric were broken for NaN values; abstime, timestamp, and interval
were broken for INVALID values; timetz was just plain broken (some
possible pairs of values were neither < nor = nor >). Also clean up
text, bpchar, varchar, and bit/varbit to eliminate duplicate code and
thereby reduce the probability of similar inconsistencies arising in
the future.
|
|
|
|
| |
Per bug report from Lieven Van Acker, 5/2/01.
|
| |
|
| |
|
| |
|