in regression tests.

Jan

Note this forces initdb because of change of Aggref node in stored rules.

shows the specific ungrouped variable being complained of.  Perhaps this
will reduce user confusion...

Jan

and pg_amop have indexes.

mentioned in FROM but not elsewhere in the query: such tables should be
joined over anyway.  Aside from being more standards-compliant, this allows
removal of some very ugly hacks for COUNT(*) processing.  Also, allow
HAVING clause without aggregate functions, since SQL does.  Clean up
CREATE RULE statement-list syntax the same way Bruce just fixed the
main stmtmulti production.
CAUTION: addition of a field to RangeTblEntry nodes breaks stored rules;
you will have to initdb if you have any rules.

make it call eval_const_expressions() so that it doesn't have to know).

they have no hardwired limit on the length of a rule's text.  Fix a couple
of minor bugs in passing --- deparsed UPDATE queries didn't have quotes
around relation name, and quotes and backslashes in constant values weren't
backslash-quoted.

RI_FKey_... constrint triggers when looking for illegal
pg_proc entries.

Jan

Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands.

TODO:
    Generic builtin trigger procedures
    Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE
    Support of new trigger type in pg_dump
    Swapping of huge # of events to disk

Jan

error message wording, due to most cases of no-such-relation now being
detected in central heap_open code rather than on an ad-hoc basis.

before comparison; if fields being joined are different widths then hashing
will yield wrong answer.  Also, remove hashjoinable mark from all uses of
array_eq, because array structures may have padding bytes between elements
and the pad bytes are of uncertain content.  This could be revisited if
array code is cleaned up.
Modify opr_sanity regress test to complain if array_eq operator is marked
hashjoinable.

more verbose results from ruleutils.c changes.

constant-coercion expression in the rules test.

every time I tweak the optimizer...

be picked for one of the complex joins in rules test ... leading to
a different output ordering ...

SELECT a/2, a/2 FROM test_missing_target GROUP BY a/2;
to be ambiguous ... which I think is correct behavior.

1. Using 100 digits after decimal point on the default
   make runtest.

2. Using 1000 digits after decimal point in a new target
   make bigtest.

At the end of 'make runtest', a hint about the new bigtest is
printed.

Jan

Jan

Jan

Jan

pg_rules to rules regression test.

Jan

in Resdom and GroupClause so changing of resno's doesn't confuse
the grouping any more.

Jan

(int2,int4,geometry).

Cheers,

Patrick Welche

definition of numeric_in.

"SYSTEM", and unpack the files in the uuencoded .tar.gz file at the end in
src/test/regress so that the int2, int4 and geometry tests pass on NetBSD/i386.
They just fail on different wording of error messages and eg printing "0"
rather than "-0". At a guess the same will be true for the other NetBSD ports,
but I can't test them.

Cheers,

Patrick

arrayfuncs.patch        fixes a small bug in my previous patches for
arrays

array-regress.patch     adds _bpchar and _varchar to regression tests

--
Massimo Dal Zotto

These are no longer used ...

pg_proc entries for array I/O routines besides the one detected by the
original patcher.  Tighten type_sanity regress test accordingly.

in rules regression test, in order to eliminate bogus test 'failures'
that occur due to platform-dependent and join-implementation-dependent
ordering of tuples.  I'm not sure that I got all of the SELECTs that need
ordering clauses --- we may need some more.  But this takes care of the
diffs between my platform and Jan's.

Previously, dates falling within Unix system time range were run through
 a call to localtime() to get the time zone, if it was not specified.
This had the effect that dates with DOMs which were larger than would be
 valid for that month were "rotated" into the following months.