moment this has no particular use except to allow table rows to be
passed to record_out(), but that case seems to be useful in itself
per recent example from Elein.  Further down the road we could look
at letting PL functions be declared to accept RECORD parameters.

so that restart doesn't fail when old postmaster died unbetimes.

are creating a new MultiXactId from two regular XIDs.  The original
coding was unnecessarily complicated and didn't save any code anyway.

output area as INTERNAL not CSTRING.  This is to prevent people from
calling the functions by hand.  This is a permanent solution for the
back branches but I hope it is just a stopgap for HEAD.

that return INTERNAL without also having INTERNAL arguments.  Since the
functions in question aren't meant to be called by hand anyway, I just
redeclared them to take 'internal' instead of 'text'.  Also add code
to ProcedureCreate() to enforce the restriction, as I should have done
to start with :-(

< * Remove unreferenced table files created by transactions that were
> * -Check for unreferenced table files created by transactions that were

files in the server log.

Heikki Linnakangas

pages. From Robert Treat.

to produce when running the executor. This is consistent with the internal
executor APIs (such as ExecutorRun), which also use a long for this purpose.
It also allows FETCH_ALL to be passed -- since FETCH_ALL is defined as
LONG_MAX, this wouldn't have worked on platforms where int and long are of
different sizes. Per report from Tzahi Fadida.

only one argument.  (Per recent discussion, the option to accept multiple
arguments is pretty useless for user-defined types, and would be a likely
source of security holes if it was used.)  Simplify call sites of
output/send functions to not bother passing more than one argument.

for a long time.

argument, since that's all they are using now.  Adjust type_sanity
regression test so that it will complain if anyone tries to define
multiple-argument output functions in future.

record object itself, rather than relying on a second OID argument to be
correct.  This patch just changes the function behavior and not the
catalogs, so it's OK to back-patch to 8.0.  Will remove the now-redundant
second argument in pg_proc in a separate patch in HEAD only.

is contention for a tuple-level lock.  This solves the problem of a
would-be exclusive locker being starved out by an indefinite succession
of share-lockers.  Per recent discussion with Alvaro.

a warning when a variable is used as a format string for printf()
and similar functions (if the variable is derived from untrusted
data, it could include unexpected formatting sequences). This
emits too many warnings to be enabled by default, but it does
flag a few dubious constructs in the Postgres tree. This patch
fixes up the obvious variants: functions that are passed a variable
format string but no additional arguments.

Most of these are harmless (e.g. the ruleutils stuff), but there
is at least one actual bug here: if you create a trigger named
"%sfoo", pg_dump will read uninitialized memory and fail to dump
the trigger correctly.

Christopher Browne

Essentially, we shoehorn in a lockable-object-type field by taking
a byte away from the lockmethodid, which can surely fit in one byte
instead of two.  This allows less artificial definitions of all the
other fields of LOCKTAG; we can get rid of the special pg_xactlock
pseudo-relation, and also support locks on individual tuples and
general database objects (including shared objects).  None of those
possibilities are actually exploited just yet, however.

I removed pg_xactlock from pg_class, but did not force initdb for
that change.  At this point, relkind 's' (SPECIAL) is unused and
could be removed entirely.

incorrect -F argument: write_msg() expects its first parameter to be a
"module name", not the format string.

> * -Implement shared row locks and use them in RI triggers

to eliminate unnecessary deadlocks.  This commit adds SELECT ... FOR SHARE
paralleling SELECT ... FOR UPDATE.  The implementation uses a new SLRU
data structure (managed much like pg_subtrans) to represent multiple-
transaction-ID sets.  When more than one transaction is holding a shared
lock on a particular row, we create a MultiXactId representing that set
of transactions and store its ID in the row's XMAX.  This scheme allows
an effectively unlimited number of row locks, just as we did before,
while not costing any extra overhead except when a shared lock actually
has to be shared.   Still TODO: use the regular lock manager to control
the grant order when multiple backends are waiting for a row lock.

Alvaro Herrera and Tom Lane.

error without affecting the entire transaction.  Valid values are
"on|interactive|off".

Dick Davies.

ExpandIndirectionStar() ... and in markTargetListOrigin() too.

expanded is of RECORD type, eg
'select (foo).* from (select foo(f1) from t1) ss'
where foo() is a function declared with multiple OUT parameters.

as FuncExpr, to cover cases where a function returning tuple is invoked
via an operator.