cleaning out temp namespaces. We don't really want the server log to be
cluttered with 'Drop cascades to table foo' every time someone uses a
temp table...
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.
correctly. However the patch for PostgresPollingStatusType() is not
included to avoid 7.3 libpq vs. pre-7.3 backend
compatibility problem. See following thread for more details.
Subject: [HACKERS] client_encoding directive is ignored in postgresql.conf
From: Tatsuo Ishii <t-ishii@sra.co.jp>
Date: Wed, 29 Jan 2003 22:24:04 +0900 (JST)
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.
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.)
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.
the index AM when we know we are fetching a unique row. However, this
logic did not consider the possibility that it would be asked to fetch
backwards. Also fix mark/restore to work correctly in this scenario.
disallowed by CREATE TABLE (eg, pseudo-types); also disallow these types
from being introduced by the range-function syntax. While at it, allow
CREATE TABLE to create zero-column tables, per recent pghackers discussion.
I am back-patching this into 7.3 since failure to disallow pseudo-types
is arguably a security hole.
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.
where it's safe to do database access. Along the way, fix core dump
for 'DEFAULT' parameters to CREATE DATABASE. initdb forced due to
change in pg_proc entry.
between signal handler and enable/disable code, avoid accumulation of
timing error due to trying to maintain remaining-time instead of
absolute-end-time, disable timeout before commit not after.
'empty declaration' warnings from compilers that care about such things.
Per discussion back before 7.2 release; we didn't do it then because
we'd already missed all the beta cycle ...
coercions, not implicit ones. For example, 'select abstime(1035497293)'
should succeed because there is an explicit binary coercion from int4
to abstime.
whose conditions might yield NULL. The negated qual to attach to the
original query is properly 'x IS NOT TRUE', not 'NOT x'. This fix
produces correct behavior, but we may be taking a performance hit because
the planner is much stupider about IS NOT TRUE than it is about NOT
clauses. Future TODO: teach prepqual, other parts of planner how to
cope with BooleanTest clauses more effectively.
Ray Ontko 28-June-02. Also, fix prefix_selectivity for NAME lefthand
variables (it was bogusly assuming binary compatibility), and adjust
make_greater_string() to not call pg_mbcliplen() with invalid multibyte
data (this last per bug report that I can't find at the moment, but it
was in July '02).
specifically ceil(), floor(), and sign(). There may be other functions
that need to be added, but this is a start. I've included some simple
regression tests.
Neil Conway
command status at the interactive level. SPI_processed, etc are set
in the same way as the returned command status would have been set if
the same querystring were issued interactively. Per gripe from
Michael Paesold 25-Sep-02.
query that uses it. This ensures that triggers will be applied consistently
throughout a query even if someone commits changes to the relation's
pg_class.reltriggers field meanwhile. Per crash report from Laurette Cisneros.
While at it, simplify memory management in relcache.c, which no longer
needs the old hack to try to keep trigger info in the same place over
a relcache entry rebuild. (Should try to fix rd_att and rewrite-rule
access similarly, someday.) And make RelationBuildTriggers simpler and
more robust by making it build the trigdesc in working memory and then
CopyTriggerDesc() into cache memory.
client
utilities (libpq.dll and psql.exe) for win32 (missing defines,
adjustments to
includes, pedantic casting, non-existent functions) per:
http://developer.postgresql.org/docs/postgres/install-win32.html.
It compiles cleanly under Windows 2000 using Visual Studio .net. Also
compiles clean and passes all regression tests (regular and contrib)
under Linux.
In addition to a review by the usual suspects, it would be very
desirable for someone well versed in the peculiarities of win32 to take
a look.
Joe Conway
