operations: make sure we use operators that are compatible, as determined
by a mergejoin link in pg_operator.  Also, add code to planner to ensure
we don't try to use hashed grouping when the grouping operators aren't
marked hashable.

are missing the FROM clause (due to a long-ago pg_dump bug).  Patch by
Stephan Szabo, minor tweaking by Tom Lane.

already fixed by You. However there were a few left and attached patch
should fix the rest of them.

I used StringInfo only in 2 places and both of them are inside debug
ifdefs. Only performance penalty will come from using strlen() like all
the other code does.

I also modified some of the already patched parts by changing
snprintf(buf, 2 * BUFSIZE, ... style lines to
snprintf(buf, sizeof(buf), ... where buf is an array.

Jukka Holappa

deleted that had another row inserted/updated to its old
value during the same statement or other statements before the
integrity check for noaction would incorrectly error.  This
could happen in deferred constraints or due to triggers or
functions. It's effectively a reworking of the previous patch that
did a not exists to instead do a separate check.

Stephan Szabo

qualified operator names directly, for example CREATE OPERATOR myschema.+
( ... ).  To qualify an operator name in an expression you need to write
OPERATOR(myschema.+) (thanks to Peter for suggesting an escape hatch).
I also took advantage of having to reformat pg_operator to fix something
that'd been bugging me for a while: mergejoinable operators should have
explicit links to the associated cross-data-type comparison operators,
rather than hardwiring an assumption that they are named < and >.

depend on this rather than the trigger argument strings to locate the
other relation to test.  This makes RI triggers function properly in
the presence of schemas and temp tables.  Along the way, fix bogus lack
of locking in RI triggers, handle quoting of names fully correctly,
compute required sizes of query buffers with some semblance of accuracy.

catalog namespace.  This will not do as a production solution because
the interpretation of RI trigger arguments will vary depending on the
current namespace search path.  I'm just putting it in so that the RI
regression tests don't fail while schema development proceeds.  We
must find a better answer before 7.3 can be released.

         * We should not even consider checking the row if it is no longer
         * valid since it was either deleted (doesn't matter) or updated
         * (in which case it'll be checked with its final values).

Stephan Szabo

o  Change all current CVS messages of NOTICE to WARNING.  We were going
to do this just before 7.3 beta but it has to be done now, as you will
see below.

o Change current INFO messages that should be controlled by
client_min_messages to NOTICE.

o Force remaining INFO messages, like from EXPLAIN, VACUUM VERBOSE, etc.
to always go to the client.

o Remove INFO from the client_min_messages options and add NOTICE.

Seems we do need three non-ERROR elog levels to handle the various
behaviors we need for these messages.

Regression passed.

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.

Stephan Szabo

Brent Verner, with review and kibitzing from Tom Lane.

tests pass.

lookup info in the relcache for index access method support functions.
This makes a huge difference for dynamically loaded support functions,
and should save a few cycles even for built-in ones.  Also tweak dfmgr.c
so that load_external_function is called only once, not twice, when
doing fmgr_info for a dynamically loaded function.  All per performance
gripe from Teodor Sigaev, 5-Oct-01.

readability.  Bizarre '(long *) TRUE' return convention is gone,
in favor of just raising an error internally in dynahash.c when
we detect hashtable corruption.  HashTableWalk is gone, in favor
of using hash_seq_search directly, since it had no hope of working
with non-LONGALIGNable datatypes.  Simplify some other code that was
made undesirably grotty by promixity to HashTableWalk.

portability issues).  Caller-visible data structures are now allocated
on MAXALIGN boundaries, allowing safe use of datatypes wider than 'long'.
Rejigger hash_create API so that caller specifies size of key and
total size of entry, not size of key and size of rest of entry.
This simplifies life considerably since each number is just a sizeof(),
and padding issues etc. are taken care of automatically.

because cached fmgr info contained reference to a shorter-lived data
structure.  Also guard against possibility that fmgr_info could fail,
leaving an incomplete entry present in the hash table.

set null/default).

semantics of RI operations.  Eventually we ought to look at making RI
work properly across inheritance trees, but not for 7.1 ...

maintained for each cache entry.  A cache entry will not be freed until
the matching ReleaseSysCache call has been executed.  This eliminates
worries about cache entries getting dropped while still in use.  See
my posting to pg-hackers of even date for more info.

id to the owner of the PK table, to avoid permission problems.

CurrentTriggerData is history.

Jan

in trigger manager.

Jan

SET DEFAULT referential action triggers.

Jan

time qualification of HeapTupleSatisfiesSnapshot()

Jan

Jan

Jan

Jan

Jan

Jan