| Age | Commit message (Collapse) | Author |
|
form '^(foo)$'. Before, these could never be optimized into indexscans.
The recent changes to make psql and pg_dump generate such patterns (for \d
commands and -t and related switches, respectively) therefore represented
a big performance hit for people with large pg_class catalogs, as seen in
recent gripe from Erik Jones. While at it, be more paranoid about
case-sensitivity checking in multibyte encodings, and fix some other
corner cases in which a regex might be interpreted too liberally.
|
|
characters in all cases. Formerly we mostly just threw warnings for invalid
input, and failed to detect it at all if no encoding conversion was required.
The tighter check is needed to defend against SQL-injection attacks as per
CVE-2006-2313 (further details will be published after release). Embedded
zero (null) bytes will be rejected as well. The checks are applied during
input to the backend (receipt from client or COPY IN), so it no longer seems
necessary to check in textin() and related routines; any string arriving at
those functions will already have been validated. Conversion failure
reporting (for characters with no equivalent in the destination encoding)
has been cleaned up and made consistent while at it.
Also, fix a few longstanding errors in little-used encoding conversion
routines: win1251_to_iso, win866_to_iso, euc_tw_to_big5, euc_tw_to_mic,
mic_to_euc_tw were all broken to varying extents.
Patches by Tatsuo Ishii and Tom Lane. Thanks to Akio Ishida and Yasuo Ohgaki
for identifying the security issues.
|
|
and 8.0. Later releases already patched.
|
|
Back-patch of previous fix in HEAD for plperl-vs-locale issue.
|
|
equal: if strcoll claims two strings are equal, check it with strcmp, and
sort according to strcmp if not identical. This fixes inconsistent
behavior under glibc's hu_HU locale, and probably under some other locales
as well. Also, take advantage of the now-well-defined behavior to speed up
texteq, textne, bpchareq, bpcharne: they may as well just do a bitwise
comparison and not bother with strcoll at all.
NOTE: affected databases may need to REINDEX indexes on text columns to be
sure they are self-consistent.
|
|
of timetz values misbehaved in --enable-integer-datetime cases, and
EXTRACT(EPOCH) subtracted the zone instead of adding it in all cases.
Backpatch to all supported releases (except --enable-integer-datetime code
does not exist in 7.2).
|
|
--enable-integer-datetimes case. Per report from Oliver Siegmar.
|
|
when a zero-month interval is given. Per discussion with Karel.
|
|
GERMAN datestyles. Ancient bug reported by Terry Lee Tucker.
|
|
Per example from Florian Pflug.
|
|
http://archives.postgresql.org/pgsql-hackers/2004-10/msg00464.php.
I plan a more permanent fix in HEAD, but for the back branches it seems
best to just touch the places that actually have a problem.
|
|
Not sure how this mistake evaded detection for so long.
|
|
case, per report from Korea PostgreSQL Users' Group. Copied from Tom
Lane's 7.4 branch patch.
|
|
functionality. Per bug report by Alvar Freude:
http://archives.postgresql.org/pgsql-bugs/2003-12/msg00022.php
|
|
octal escape all octets outside the range 0x20 to 0x7e. This fixes
the problem pointed out by Sergey Yatskevich here:
http://archives.postgresql.org/pgsql-bugs/2003-11/msg00140.php
|
|
rule split the query into one INSERT and one UPDATE where the UPDATE
then hit's the just created row without modifying the key fields again.
In this special case, the new key slipped in totally unchecked.
Jan
|
|
in the schema search path. Otherwise pg_dump doesn't correctly dump
scenarios where a custom opclass is created in 'public' and then used
by indexes in other schemas.
|
|
|
|
From Karel Zak.
|
|
in HAVE_INT64_TIMESTAMP cases, including two potential stack smashes
when more than six fractional digits were supplied. Per bug report
from Philipp Reisner.
|
|
|
|
|
|
does not dump core.
|
|
|
|
|
|
work at all, and neither case behaved sanely for negative intervals.
|
|
does not change on UPDATE.
|
|
Per recent discussion on pgsql-general, this is appropriate for spec
compliance, and has the nice side-effect of easing porting from old
pg_dump files that exhibit the 59.999=>60.000 roundoff problem.
|
|
as the correct user, not only query execution. Per report from Sean
Chittenden.
|
|
Will patch separately but equivalently in HEAD.
|
|
|
|
account for NULLs; in hindsight this is obvious since the code for
the MCV-lists case would reduce to this when there are zero entries
in both lists. Per example from Alec Mitchell.
|
|
|
|
bogus than it was. Per bug report from Adrian Pop.
|
|
from Andreas Pflug.
|
|
Per report from Dave Marin.
|
|
is assumed to be in local time, not GMT. This improves consistency with
other operations, which all assume local timezone when it matters. Per
bug #897.
|
|
answer when SET TIMEZONE has been done since the start of the current
transaction. Per bug report from Robert Haas.
I plan some futher cleanup in HEAD, but this is a low-risk patch for
the immediate issue in 7.3.
|
|
|
|
value of MAX_TIME_PRECISION in floating-point-timestamp-storage case
from 13 to 10, which is as much as time_out is actually willing to print.
(The alternative of increasing the number of digits we are willing to
print looks risky; we might find ourselves printing roundoff garbage.)
|
|
example from RaÇl GutiÅrrez.
|
|
datetime token tables. Even more embarrassing, the regression tests
revealed some of the problems --- but evidently the bogus output wasn't
questioned. Add code to postmaster startup to directly check the tables
for correct ordering, in hopes of not being embarrassed like this again.
|
|
per gripe from Csaba Nagy. There is still potential for platform-specific
behavior for values that are exactly halfway between integers, but at
least we now get the expected answer for all other cases.
|
|
> The big problem is that while pg_dump's dump_trigger() looks at
> tginitdeferred and dumps accordingly, pg_get_constraintdef doesn't look
> at tginitdeferred, and therefore doesn't record the requirement as part
> of ALTER TABLE ADD CONSTRAINT.
pg_get_constraintdef should probably be looking at condeferrable and
condeferred in the pg_constraint row it's looking at. Maybe something
like the attached.
(Added, output only non-default values.)
Stephan Szabo
|
|
Kenji Sugita
|
|
|
|
|
|
results due to doing arithmetic on uninitialized values. Add some
documentation about the AT TIME ZONE construct. Update some other
date/time documentation that seemed out of date for 7.3.
|
|
meaning +1300.
|
|
anymore given the mktime() workaround now done in DetermineLocalTimeZone.
This has now been confirmed by Robert Bruccoleri for Irix, and I'm going
to extrapolate to AIX as well.
|