in regression tests.

Jan

Jan

backend/Makefiles to be patched could significantly be reduced since
they
have been adopted to the QNX4 needs.

Andreas Kardos

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...

one in production PGLIB.

Jan

regress test expected outputs for change in 'Cannot insert a duplicate key'
error message wording.

as that test finishes --- helps to give the impression that something is
happening...

to be accepted, but constraints regress test was expecting it to fail.

script.  This is way cool...

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.

expressions in CREATE TABLE.  There is no longer an emasculated expression
syntax for these things; it's full a_expr for constraints, and b_expr
for defaults (unfortunately the fact that NOT NULL is a part of the
column constraint syntax causes a shift/reduce conflict if you try a_expr.
Oh well --- at least parenthesized boolean expressions work now).  Also,
stored expression for a column default is not pre-coerced to the column
type; we rely on transformInsertStatement to do that when the default is
actually used.  This means "f1 datetime default 'now'" behaves the way
people usually expect it to.
BTW, all the support code is now there to implement ALTER TABLE ADD
CONSTRAINT and ALTER TABLE ADD COLUMN with a default value.  I didn't
actually teach ALTER TABLE to call it, but it wouldn't be much work.

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

* Buffer refcount cleanup (per my "progress report" to pghackers, 9/22).
* Add links to backend PROC structs to sinval's array of per-backend info,
and use these links for routines that need to check the state of all
backends (rather than the slow, complicated search of the ShmemIndex
hashtable that was used before).  Add databaseOID to PROC structs.
* Use this to implement an interlock that prevents DESTROY DATABASE of
a database containing running backends.  (It's a little tricky to prevent
a concurrently-starting backend from getting in there, since the new
backend is not able to lock anything at the time it tries to look up
its database in pg_database.  My solution is to recheck that the DB is
OK at the end of InitPostgres.  It may not be a 100% solution, but it's
a lot better than no interlock at all...)
* In ALTER TABLE RENAME, flush buffers for the relation before doing the
rename of the physical files, to ensure we don't get failures later from
mdblindwrt().
* Update TRUNCATE patch so that it actually compiles against current
sources :-(.
You should do "make clean all" after pulling these changes.

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.

combinations of query-plan-type backend options.  Good for testing
planner/optimizer.  Tedious, though.

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.