| Age | Commit message (Collapse) | Author |
|---|
|
Instead of grovelling through pg_class to find them, make use of the
handy dandy dependency mechanism: just delete everything that depends
on our temp schema. Unlike the pg_class scan, the dependency mechanism
is smart enough to delete things in an order that doesn't fall foul of
any dependency restrictions. Fixes problem reported by David Heggie:
a temp table with a serial column may cause a backend FATAL exit at
shutdown time, if it chances to try to delete the temp sequence first.
|
|
reported by Stefanos Harhalakis 2/2/2003.
|
|
per report from Ian Harding.
|
|
|
|
construction 'SETOF type[]' which for some reason was previously
overlooked (you'd have to name the array type directly to make it work).
|
|
|
|
|
|
either end of subplan results. This prevents misbehavior of cursors
on SELECT DISTINCT ... queries. Per bug report 1-Feb-02.
|
|
restriction was debatable to begin with, but it has now become obvious
that it breaks forward-porting of user-defined types; contrib/lo being
the most salient example.
|
|
columns of type lo (see contrib/lo). Rather than hacking the function
definitions on-the-fly, just modify the queries issued by FixupBlobRefs
so that they work even if CREATE CAST hasn't been issued.
|
|
files. Fix it.
|
|
user names. Per recent reports.
|
|
interp pointer. Per report from Gerhard Hintermayer.
|
|
connection shutdown. This is a grotty workaround for a Tcl bug, but
said bug has been there long enough that I'm not holding my breath
for a real fix. Per discussions and testing from ljb and g.hintermayer.
|
|
From Andrew Bosma.
|
|
with some amount of cleanliness. I see no need to report the internal
Python name rather than the SQL procedure name in error tracebacks.
|
|
bison 1.875 and later as we did from earlier bison releases. Eventually
we will probably want to adopt the newer message spelling ... but not yet.
Per recent discussion on pgpatches.
Note: I didn't change the build rules for bootstrap, ecpg, or plpgsql
grammars, since these do not affect regression test results.
|
|
From Neil Conway.
|
|
|
|
a tuple table. Fixes core dump in pltcl (and probably other PLs) when
executing a query rewritten by a rule. Per bug report from Wolfgang Walter.
|
|
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.)
|
|
|
|
in GUCArrayAdd/GUCArrayDelete. This prevents the multiple-entry bug
exhibited by Frank Lupo 28-Jan-2003.
|
|
Set log_min_error_messages to the proper and agreed-upon default, PANIC
(off). (BACKPATCH)
|
|
Problem reported and fixed by Oliver Elphick.
|
|
silly buffer overrun (someone needs to learn to count characters...)
|
|
|
|
for backwards compatibility with pre-7.3 behavior. Per discussion on
pgsql-general and pgsql-hackers.
|
|
example from RaÇl GutiÅrrez.
|
|
that's selecting into a RECORD variable returns zero rows, make it
assign an all-nulls row to the RECORD; this is consistent with what
happens when the SELECT INTO target is not a RECORD. In support of
this, tweak the SPI code so that a valid tuple descriptor is returned
even when a SPI select returns no rows.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
Modified Files:
Tag: REL7_3_STABLE
jdbc/org/postgresql/jdbc1/AbstractJdbc1ResultSet.java
jdbc/org/postgresql/test/jdbc2/TimestampTest.java
|
|
fix uses explicit joins to avoid using the genetic query optimizer for
consistent results.
Modified Files:
Tag: REL7_3_STABLE
jdbc/org/postgresql/jdbc1/AbstractJdbc1DatabaseMetaData.java
|
|
direction on HP-UX; our former approach has been obsolete since HPUX 9.
Giles Lean
|
|
|
|
>
> I'd suggest that the runtime.sgml description explicitly say "values of
> at least a few thousand are recommended for production installations".
Neil Conway
|
|
RELEASE_CHANGES.
Manfred Koizar
|
|
|
|
|
|
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.
|
|
|
|
believe I didn't notice this before -- once 64k was sent to/from the
server the client would crash. Basicly, in 7.3 the server SSL code set
the initial state to "about to renegotiate" without actually starting
the renegotiation. In addition, the server and client didn't properly
handle the SSL_ERROR_WANT_(READ|WRITE) error. This is fixed in the
second patch.
Nathan Mueller
|
|
first, that I missed when checking over 7.3.1, was that the client
method was switched to SSLv23 along with the server. The SSLv23 client
method does SSLv2 by default, but can also understand SSLv3. In our
situation the SSLv2 backwords compatibility is really only needed on the
server. This is the first patch.
The last thing is that I found a way for the server to understand SSLv2
HELLO messages (sent by pre-7.3 clients) but then get them to talk
SSLv3. This is the last one.
Nathan Mueller
|
|
> 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
|
|
on its namespace, so that it will go away if the schema is dropped.
|
