| Age | Commit message (Collapse) | Author |
|---|
|
(per recent discussion with Tatsuo). Hopefully the compilers with
that old bug are all long gone.
|
|
|
|
|
|
microseconds < 100000 should be displayed as, eg, 13.000126, not 13.126.
|
|
in Turkish locale. Keywords are now checked under pure ASCII case-folding
rules ('A'-'Z'->'a'-'z' and nothing else). However, once a word is
determined not to be a keyword, it will be case-folded under the current
locale, same as before. See pghackers discussion 20-Feb-01.
|
|
|
|
the old ones were not small enough to ensure r-tree and gist indexes would
get picked when available. These numbers are totally bogus anyway, but
in the absence of any real estimation technique, we'd like to select
indexes when available ...
|
|
clause with an alias is a <subquery> and therefore hides table references
appearing within it, according to the spec. This is the same as the
preliminary patch I posted to pgsql-patches yesterday, plus some really
grotty code in ruleutils.c to reverse-list a query tree with the correct
alias name depending on context. I'd rather not have done that, but unless
we want to force another initdb for 7.1, there's no other way for now.
|
|
as previously discussed.
It makes AIX and IRIX not use DST for dates before 1970.
The following expected files need to be removed from the regression tests,
they contain wrong results and are not needed any more.
src/test/regress/expected/horology-1947-PDT.out
src/test/regress/expected/tinterval-1947-PDT.out
src/test/regress/expected/abstime-1947-PDT.out
Zeugswetter Andreas
|
|
|
|
are now separate files "postgres.h" and "postgres_fe.h", which are meant
to be the primary include files for backend .c files and frontend .c files
respectively. By default, only include files meant for frontend use are
installed into the installation include directory. There is a new make
target 'make install-all-headers' that adds the whole content of the
src/include tree to the installed fileset, for use by people who want to
develop server-side code without keeping the complete source tree on hand.
Cleaned up a whole lot of crufty and inconsistent header inclusions.
|
|
future 'timestamp without time zone', which SQL claims is equivalent to
plain 'timestamp'.
|
|
truncating to integer. Remove regress test that checks whether
4567890123456789 can be converted to float without loss; since that's
52 bits, it's on the hairy edge of failing with IEEE float8s, and indeed
rint seems to give platform-dependent results for it.
|
|
|
|
bothering to check the return value --- which meant that in case the
update or delete failed because of a concurrent update, you'd not find
out about it, except by observing later that the transaction produced
the wrong outcome. There are now subroutines simple_heap_update and
simple_heap_delete that should be used anyplace that you're not prepared
to do the full nine yards of coping with concurrent updates. In
practice, that seems to mean absolutely everywhere but the executor,
because *noplace* else was checking.
|
|
mixed-signs. Previous effort left way too many minus signs, and was at
least as broken as the one before that :(
Clean up "ISO-style" time interval representation to omit zero fields if
there is at least one non-zero field. Supress some leading plus signs
when not necessary for clarity.
Replace every #ifdef __CYGWIN__ block with a cleaner TIMEZONE_GLOBAL macro
defined in datetime.h.
|
|
Not sure why some were this way, and others were already correct, but it
seems to have been like this for several years.
This caused problems on a few damaged platforms like AIX and IRIX which do
not support DST calculations for years before 1970.
Thanks to Andreas Zeugswetter <ZeugswetterA@wien.spardat.at> for finding
the problem.
|
|
it now returns true if the aclitem argument exactly matches any one of
the elements of the aclitem[] argument. Per complaint from Wolff 1/10/01.
|
|
from sergiop@sinectis.com.ar.
|
|
Previous result did not have correct month boundaries so anything near edge
cases was suspect (e.g. April was in Q1 and July, August were lumped into
Q2).
Thanks to Denis Osadchy <osadchy@turbo.nsk.su> for the report.
|
|
for 64-bit platforms ...
|
|
1. Distinguish cases where a Datum representing a tuple datatype is an OID
from cases where it is a pointer to TupleTableSlot, and make sure we use
the right typlen in each case.
2. Make fetchatt() and related code support 8-byte by-value datatypes on
machines where Datum is 8 bytes. Centralize knowledge of the available
by-value datatype sizes in two macros in tupmacs.h, so that this will be
easier if we ever have to do it again.
|
|
according to the ANSI C spec, (b) gets the boundary conditions right,
and (c) is about a third as long and three times more intelligible.
|
|
64-bit machines. Also, make oidvectorin use the same code as oidin.
|
|
semantics of RI operations. Eventually we ought to look at making RI
work properly across inheritance trees, but not for 7.1 ...
|
|
recommendation from Paul Vixie. Add a new abbrev() function to produce
abbreviated format as text. No forced initdb, but new function is not
available unless you do an initdb or add the pg_proc row manually.
|
|
> Date: Thu, 14 Dec 2000 12:44:47 +0100 (CET)
> From: Kovacs Zoltan Sandor <tip@pc10.radnoti-szeged.sulinet.hu>
> To: pgsql-bugs@postgresql.org
> Subject: [BUGS] to_char() causes backend to close connection
>
> Hi, this query gives different strange results:
>
> select to_char(now()::abstime,'YYMMDDHH24MI');
>
> I get e.g. a "backend closed the channel unexpectedly..." error with
> successful or failed resetting attempt (indeterministic)
Again thanks Kovacs, you found really designing bug, that appear
if anyone write bad format template to "number" version of to_char()
(as you with 'DD').
Karel
|
|
|
|
is the only diff not accounted for by fmgr rewrite...
|
|
varlena type. (I did not force initdb, but you won't see the fix
unless you do one.) Also, make sure all index support operators and
functions are careful not to leak memory for toasted inputs; I had
missed some hash and rtree support ops on this point before.
|
|
length is less than original string length.
|
|
As I read it, the spec requires a non-null result in some cases where
one of the inputs is NULL: specifically, if the other endpoint of that
interval is between the endpoints of the other interval, then the result
is known TRUE despite the missing endpoint. The spec could've been a
lot simpler if they did not intend this behavior.
I did not force an initdb for this change, but if you don't do one you'll
still see the old strict-function behavior.
|
|
|
|
values, whether the local char type is signed or not. This is necessary
for portability. Per discussion on pghackers around 9/16/00.
|
|
Allow some operator-like tokens to be used as function names.
Flesh out support for time, timetz, and interval operators
and interactions.
Regression tests pass, but non-reference-platform horology test results
will need to be updated.
|
|
immediately uncovered three of Karel's own bugs, including a routine
that scribbled on its input (naughty naughty!)
|
|
for a now-vanished group. Instead, display the numeric group ID, same
as it does for vanished users.
|
|
types.
|
|
for any other purpose than PGLC_localeconv()'s internal save/restore of
locale settings. Fix cash.c to call PGLC_localeconv() rather than
making a direct call to localeconv() --- the old way, if PGLC_localeconv()
had already cached a locale result, it would be overwritten by the first
cash_in or cash_out operation, leading to wrong-locale results later.
Probably no demonstrable bug today, since we only appear to be looking
at the LC_MONETARY results which should be the same anyway, but definitely
a gotcha waiting to strike.
|
|
shifting by the word width is not defined by ANSI C...
|
|
re-adopt these settings at every postmaster or standalone-backend startup.
This should fix problems with indexes becoming corrupt due to failure to
provide consistent locale environment for postmaster at all times. Also,
refuse to start up a non-locale-enabled compilation in a database originally
initdb'd with a non-C locale. Suppress LIKE index optimization if locale
is not "C" or "POSIX" (are there any other locales where it's safe?).
Issue NOTICE during initdb if selected locale disables LIKE optimization.
|
|
it fixing Y,YY,YYY,YYYY conversion, the docs and regress tests update
are included too.
During the patch testing I found small bug in miscadmin.h in
convertstr() declaration. Here it's fixed too.
Thanks
Karel
|
|
From Adriaan Joubert <a.joubert@albourne.com>
|
|
|
|
|
|
|
|
rather than just being aliases for int4in/int4out. Give type Oid a
full set of comparison operators that do proper unsigned comparison,
instead of reusing the int4 comparators. Since pg_dump is now doing
unsigned comparisons of OIDs, it is now *necessary* that we play by
the rules here. In fact, given that btoidcmp() has been doing unsigned
comparison for quite some time, it seems likely that we have index-
corruption problems in 7.0 and before once the Oid counter goes past
2G. Fixing these operators is a necessary step before we can think
about 8-byte Oid, too.
|
|
'b' prefixes.
|
|
where char is signed by default.
|
|
with an -fsigned-char/-funsigned-char setting opposite to that of libc,
thus breaking the convention that 'undefined' values returned by
localeconv() are represented by CHAR_MAX. It is sheer stupidity that
gcc even has such a switch --- it's just as bad as the structure-packing
control switches offered by the more brain-dead PC compilers --- and
as for the behavior of Linux distribution vendors who set RPM_OPT_FLAGS
differently from the way they built libc, well, words fail me...
|
