Neil Conway [Fri, 17 Dec 2004 03:51:36 +0000 (03:51 +0000)]
Allow 'ELSEIF' as an alternative to 'ELSIF' in PL/PgSQL. There have been
several reports of users being confused when they attempt to use ELSEIF
and run into trouble due to PL/PgSQL's lax parser. The parser will be
improved for 8.1, but we can fix most of the problem by allowing ELSEIF
for now.
Tom Lane [Thu, 16 Dec 2004 20:41:01 +0000 (20:41 +0000)]
Cause configure --with-tcl to check for presence of <tcl.h>, as per
gripe from John Gray. Also fix thinko in pltcl Makefile: if a special
Tcl include directory is specified, that ought to be searched first.
Tom Lane [Wed, 15 Dec 2004 21:13:34 +0000 (21:13 +0000)]
Fix another place broken by new List implementation :-(. Per example
from goranpop@nspoint.net. I think this escaped notice because in
simple cases the list is NIL on entry.
Tom Lane [Wed, 15 Dec 2004 20:15:17 +0000 (20:15 +0000)]
Disallow SETOF in the input of parseTypeString(). Formerly it was
silently ignored, allowing one to write bizarre things like
DECLARE x setof int;
in plpgsql. This has misled at least one novice into thinking that
plpgsql variables could be sets ...
Tom Lane [Tue, 14 Dec 2004 22:50:23 +0000 (22:50 +0000)]
In 'make installcheck' for contrib/, insert 'sleep 1' between subdirectory
checks, to ensure the previous test backend has time to quit out of the
regression database. Also, allow all the checks to be run even if one
of them fails. Per suggestions from Andrew Dunstan to improve the
usefulness of buildfarm testing.
Tom Lane [Tue, 14 Dec 2004 22:16:32 +0000 (22:16 +0000)]
Cope with circularities involving a view's ON SELECT rule. I originally
thought there couldn't be any, but the folly of this was exposed by an
example from andrew@supernews.com 5-Dec-2004. The patch applies the
identical logic already used for table constraints and defaults to ON
SELECT rules, so I have reasonable confidence in it even though it might
look like complicated logic.
Tom Lane [Tue, 14 Dec 2004 21:35:20 +0000 (21:35 +0000)]
Fix pg_dump to ensure that a comment on a table CHECK constraint cannot
be emitted too soon. The previous code got this right in the case where
the CHECK was emitted as a separate ALTER TABLE command, but not in the
case where the CHECK is emitted right in CREATE TABLE. Per report from
Slawomir Sudnik.
Note: this code is pretty ugly; it'd perhaps be better to treat comments
as independently sortable dump objects. That'd be much too invasive a
change for RC time though.
Neil Conway [Tue, 14 Dec 2004 01:59:41 +0000 (01:59 +0000)]
Prevent pg_resetxlog from being run as root. If this is allowed, some
root-owned files will be written to the data directory, leaving it in an
unusable state.
Bruce Momjian [Mon, 13 Dec 2004 14:21:32 +0000 (14:21 +0000)]
Add:
>
> * Allow the size of the buffer cache used by temporary objects to be
> specified as a GUC variable
>
> Larger local buffer cache sizes requires more efficient handling of
> local cache lookups.
Tom Lane [Sun, 12 Dec 2004 20:17:06 +0000 (20:17 +0000)]
PREPARE and EXPLAIN need to copy the source query just like we recently
had to do in DECLARE CURSOR. AFAICS these are all the places affected.
PREPARE case per example from Michael Fuhr, EXPLAIN case located by
grepping for planner calls ...
Tom Lane [Sun, 12 Dec 2004 05:07:50 +0000 (05:07 +0000)]
Upgrade formrdesc() so that it can correctly initialize the tupledesc
(rd_att) field of a nailed-in-cache relcache entry. This fixes the bug
reported by Alvaro 8-Dec-2004; I believe it probably also explains
Grant Finnemore's report of 10-Sep-2004.
In an unrelated change in the same file, put back 7.4's response to
failure to rename() the relcache init file, ie, unlink the useless
temp file. I did not put back the warning message, since there might
actually be some reason not to have that.
Tom Lane [Sat, 11 Dec 2004 23:26:51 +0000 (23:26 +0000)]
Instead of supposing (wrongly, in the general case) that the rowtype
of an inheritance child table is binary-compatible with the rowtype of
its parent, invent an expression node type that does the conversion
correctly. Fixes the new bug exhibited by Kris Shannon as well as a
lot of old bugs that would only show up when using multiple inheritance
or after altering the parent table.
Tom Lane [Fri, 3 Dec 2004 22:19:28 +0000 (22:19 +0000)]
As long as we're forcing an ORDER BY in these four join queries, we had
better make sure the sort order is totally specified; else we get burnt
by platform-specific behavior of qsort() with equal keys. Per buildfarm
results.
Tom Lane [Fri, 3 Dec 2004 21:26:31 +0000 (21:26 +0000)]
Use StrNCpy not strncpy to fill hash key, to ensure the resulting key
is null-terminated. I think this is not a real bug because the parser
would always have truncated the identifier to NAMEDATALEN-1 already,
but let's be safe. Per report from Klocwork.
Bruce Momjian [Fri, 3 Dec 2004 17:13:28 +0000 (17:13 +0000)]
> If it bothers you that much. I'd make a flag, cleared at the start of
> each COPY, and then where we test for CR or LF in CopyAttributeOutCSV,
> if the flag is not set then set it and issue the warning.
Bruce Momjian [Fri, 3 Dec 2004 17:12:09 +0000 (17:12 +0000)]
>>This patch adds another plpgsql trigger example to the chapter. It uses
>>the emp table again, but shows how to audit changes into another table
>>(emp_audit).
Tom Lane [Thu, 2 Dec 2004 23:20:21 +0000 (23:20 +0000)]
Code review for recent libpq changes. Be more careful about error
handling in SIGPIPE processing; avoid unnecessary pollution of application
link-symbol namespace; spell 'pointer to function' in the conventional
way.
Bruce Momjian [Thu, 2 Dec 2004 22:51:28 +0000 (22:51 +0000)]
> I have installed your patch and adjusted the names of the standards
> throughout to the spellings suggested by your book.
Great.
A follow-up patch for current CVS HEAD is attached, and available at
http://troels.arvin.dk/db/pgsql/conformance/pgsql-sql-conformance-
followup.patch
The patch
- includes a core feature ID that had been left
out by mistake (C011)
- updates the sql_feature_packages.txt table to
reflect changes in SQL:2003 which were not
covered properly in my last patch
Bruce Momjian [Thu, 2 Dec 2004 22:48:10 +0000 (22:48 +0000)]
> > 8.0beta3 has pg_autovacuum included, when I want to run this as a
> > Windows service, it says you can use the -I and -R options.
> >
> > When I do that and I specify a password with '-P'
> (uppercase) then in
> > the registry it's saved as '-p' (lowercase) in the
> service-commandline
> > (ImagePath).
This was fixed in v1.21 of pg_autovacuum.c, That rev is tagged for
beta3, so you should not be seeing this issue unless you actually have
an older version for some reason.
> > Also it removes the quotes I added and I'm not so sure it
> would work
> > the way it's supposed to, without it.
It's not so much that it strips them (that happens automagically), more
that it doesn't re-add them when it writes the command line in the
registry. The attached patch fixes that by simply quoting all options
that may need it.
> > If you add DependOnService (a REG_MULTI_SZ an
> array-like-thingie) and
> > have the name (in this case: pgsql-8.0-beta2-dev3) of a service it
> > depends on, it will not fail to start (it will not even try, as
> > PostgreSQL is not running), when PostgreSQL already failed.
> >
> > Maybe it's an idea to specify it on the commandline (what
> service to
> > depend on).
A -E <service> option is added in the attached patch.
Bruce Momjian [Thu, 2 Dec 2004 22:40:18 +0000 (22:40 +0000)]
> I enclose a short patch to reduce the PGARCH_RESTART_INTERVAL from 60
> seconds to 10 seconds. The original number was plucked from thin air
> some months ago, and I'd like to review that now based upon further
> thought, observation and experience.
>
> This change has little or no effect on performance, since the interval
> is there mainly to avoid repeated respawn attempts if archiver fails at
> startup. Archiver start-up time is very quick, so there is little danger
> of exceeding 10 seconds.
>
> On a busy system, if the archiver does die, then many files can build up
> in the 60 seconds before respawning. That xlog file backlog could take
> some time to clear. This then leaves a larger than normal window of data
> loss for a possibly long period.
>
> It's a minor change only, with no other effect on function.