Tom Lane [Wed, 14 Nov 2001 22:14:22 +0000 (22:14 +0000)]
Try to be a little less terse about dealing with variable-length structs
in C, but recommend that newbies who don't recognize this trick should do
some studying ...
Barry Lind [Wed, 14 Nov 2001 04:11:37 +0000 (04:11 +0000)]
Attached is a patch against the CVS repository that fixes the ResultSet absolute() problem.
There's also a little fix for the getRow() method. While fixing
absolute(), I noticed that getRow() wasn't quite following the spec: it
wasn't returning 0 when the ResultSet wasn't positioned on a row. I've
started a ResultSet test case and included it as well.
Tom Lane [Mon, 12 Nov 2001 21:04:46 +0000 (21:04 +0000)]
Tweak parser so that there is a defined representation for datatypes
bpchar, bit, numeric with typmod -1. Alter format_type so that this
representation is printed when the typmod is -1. This ensures that
tables having such columns can be pg_dump'd and reloaded correctly.
Also, remove the rather useless and non-SQL-compliant default
precision and scale for type NUMERIC. A numeric column declared as
such (with no precision/scale) will now have typmod -1 which means
that numeric values of any precision/scale can be stored in it,
without conversion to a uniform scale. This seems significantly
more useful than the former behavior. Part of response to bug #513.
Tom Lane [Mon, 12 Nov 2001 20:05:24 +0000 (20:05 +0000)]
If the alternatives for a CASE construct all have the same typmod,
use that typmod not -1 as the typmod of the CASE result.
Part of response to bug#513.
Tom Lane [Mon, 12 Nov 2001 20:04:20 +0000 (20:04 +0000)]
If the inputs of a UNION/INTERSECT/EXCEPT construct all agree on the
typmod of a particular column, mark the output with that same typmod,
not -1 as formerly. -1 is still used if there is any disagreement.
Part of response to bug#513.
Barry Lind [Mon, 12 Nov 2001 19:59:46 +0000 (19:59 +0000)]
fixed bug in ResultSet. Version 1.29 backed out two previous fixes (1.26 and 1.25). This checkin add back those two previous fixes. Problem reported by Daniel Germain
Tom Lane [Mon, 12 Nov 2001 17:18:06 +0000 (17:18 +0000)]
Repair crash in EvalPlanQual of query involving nestloop with inner
index scan. Problem was that link to outer tuple wasn't being stored
everyplace it needed to be.
Tom Lane [Mon, 12 Nov 2001 15:57:08 +0000 (15:57 +0000)]
psql's \do was going out of its way to lie about the result type of
operators. Should report the declared oprresult type, not the return type
of the underlying proc, which might be only binary-compatible (cf.
textcat entries).
Bruce Momjian [Mon, 12 Nov 2001 06:09:09 +0000 (06:09 +0000)]
Tables without oids wouldn't be able to be
used inside fk constraints, since some of the checks
in the trigger did a SELECT oid. Since the oid wasn't
actually used, I changed this to SELECT 1. My test
case with non-oid tables now works and fk regression
appears to run fine on my machine.
Tom Lane [Mon, 12 Nov 2001 04:54:08 +0000 (04:54 +0000)]
Suppress duplicate error messages in pq_flush. Write error messages to
postmaster log with elog(DEBUG) so that they will be timestamped etc.
Once upon a time I think elog() was unsafe here, but it shouldn't be anymore.
Tom Lane [Sun, 11 Nov 2001 20:33:53 +0000 (20:33 +0000)]
In find_mergeclauses_for_pathkeys, it's okay to return multiple merge
clauses per path key. Indeed, we *must* do so or we will be unable to
form a valid plan for FULL JOIN with overlapping join conditions, eg
select * from a full join b on
a.v1 = b.v1 and a.v2 = b.v2 and a.v1 = b.v2.
Tom Lane [Sun, 11 Nov 2001 19:18:54 +0000 (19:18 +0000)]
sort_inner_and_outer needs a check to ensure that it's consumed all the
mergeclauses in RIGHT/FULL join cases, just like the other routines have.
I'm not quite sure why I thought it didn't need one --- but Nick
Fankhauser's recent bug report proves that it does.
Tom Lane [Sat, 10 Nov 2001 22:31:49 +0000 (22:31 +0000)]
Allow TIMESTAMP, VARCHAR, et al to be used as unquoted column names,
though alas not as unquoted function names. De-reserve a bunch of
keywords that could have been in ColId rather than ColLabel all along.
Per recent proposal in pgsql-patches.
Tom Lane [Tue, 6 Nov 2001 18:02:48 +0000 (18:02 +0000)]
Clean up formatting of child process exit-status reports so that they
are correct, consistent, and complete ... motivated by gripe from
Oliver Elphick, but I see someone had already made an incomplete stab
at this.