remove the ancient (and always pretty dodgy) assumption in parse_clause.c
that a query can't have an empty targetlist.

rather than allowing them only in a few special cases as before.  In
particular you can now pass a ROW() construct to a function that accepts
a rowtype parameter.  Internal generation of RowExprs fixes a number of
corner cases that used to not work very well, such as referencing the
whole-row result of a JOIN or subquery.  This represents a further step in
the work I started a month or so back to make rowtype values into
first-class citizens.

* ALTER ... ADD COLUMN with defaults and NOT NULL constraints works per SQL
spec.  A default is implemented by rewriting the table with the new value
stored in each row.

* ALTER COLUMN TYPE.  You can change a column's datatype to anything you
want, so long as you can specify how to convert the old value.  Rewrites
the table.  (Possible future improvement: optimize no-op conversions such
as varchar(N) to varchar(N+1).)

* Multiple ALTER actions in a single ALTER TABLE command.  You can perform
any number of column additions, type changes, and constraint additions with
only one pass over the table contents.

Basic documentation provided in ALTER TABLE ref page, but some more docs
work is needed.

Original patch from Rod Taylor, additional work from Tom Lane.

	FORCE QUOTE to force quotes
	FORCE NOT NULL to quote null input values

        o -Allow dump/load of CSV format

This adds new keywords to COPY and \copy:

        CSV - enable CSV mode (comma separated variable)
        QUOTE - specify quote character
        ESCAPE - specify escape character
        FORCE - force quoting of specified column
	LITERAL - suppress null comparison for columns

Doc changes included.  Regression updates coming from Andrew.

are sought first as local FROM columns, then as local SELECT-list aliases,
and finally as outer FROM columns; the former behavior made outer FROM
columns take precedence over aliases.  This does not change spec
conformance because SQL99 allows only the first case anyway, and it seems
more useful and self-consistent.  Per gripe from Dennis Bjorklund 2004-04-05.

Fabien COELHO

transformed whole-row variables.  Cleaner to use regular whole-row Vars.

results with tuples as ordinary varlena Datums.  This commit does not
in itself do much for us, except eliminate the horrid memory leak
associated with evaluation of whole-row variables.  However, it lays the
groundwork for allowing composite types as table columns, and perhaps
some other useful features as well.  Per my proposal of a few days ago.

is measured in kilobytes and checked against actual physical execution
stack depth, as per my proposal of 30-Dec.  This gives us a fairly
bulletproof defense against crashing due to runaway recursive functions.

errors in internally-generated queries, such as those submitted by
plpgsql functions.  Per recent discussions with Fabien Coelho.

so that the 'val' is computed only once, per recent discussion.  The
speedup is not much when 'val' is just a simple variable, but could be
significant for larger expressions.  More importantly this avoids issues
with multiple evaluations of a volatile 'val', and it allows the CASE
expression to be reverse-listed in its original form by ruleutils.c.

implemented casts to varchar and bpchar using a cast-to-text function.
This is a holdover from before we had pg_cast; it now makes more sense
to just list these casts in pg_cast.  While at it, add pg_cast entries
for the other direction (casts from varchar/bpchar) where feasible.

Fabien COELHO

is still lacking, as is support in plpgsql and other places, but this is
the basic feature.  Patch by Andrew Dunstan, some tweaking by Tom Lane.
Also, enable %option nodefault in these two lexers, and patch some gaps
revealed thereby.

problem, per previous discussion.  Make some additional changes to
centralize the knowledge of just how identifier downcasing is done,
in hopes of simplifying any future tweaking in this area.

backend lexer against psql's.

bit more helpful by identifying the specific qualified name being
complained of.

unnecessary checks for complex grouping expressions: we cannot check
whether the expressions are simple Vars until after we apply
flatten_join_alias_vars, because in the case of FULL JOIN that routine
can introduce non-Var expressions.  Per example from Joel Knight.

patch: a 3-value enum was mistakenly assigned directly to a 'bool'
in transformCreateStmt(). Along the way, change makeObjectName()
to be static, as it isn't used outside analyze.c

for sure...).  Rather than relying on the query context of a rangetable
entry to identify what permissions it wants checked, store a full AclMode
mask in each RTE, and check exactly those bits.  This allows an RTE
specifying, say, INSERT privilege on a view to be copied into a derived
UPDATE query without changing meaning.  Per recent discussion thread.
initdb forced due to change of stored rule representation.

expressions supported by CREATE SCHEMA.

Also added the beginning of some regression tests for CREATE SCHEMA;
plenty more work is needed here.

intended to allow application authors to insulate themselves from
changes to the default value of 'default_with_oids' in future releases
of PostgreSQL.

This patch also fixes a bug in the earlier implementation of the
'default_with_oids' GUC variable: code in gram.y should not examine
the value of GUC variables directly due to synchronization issues.

TRANSACTION.

pointer type when it is not necessary to do so.

For future reference, casting NULL to a pointer type is only necessary
when (a) invoking a function AND either (b) the function has no prototype
OR (c) the function is a varargs function.

parameters to be declared with names.  pg_proc has a column to store
names, and CREATE FUNCTION can insert data into it, but that's all as
yet.  I need to do more work on the pg_dump and plpgsql portions of the
patch before committing those, but I thought I'd get the bulky changes
in before the tree drifts under me.
initdb forced due to pg_proc change.

readability and for the sake of consistency with the rest of analyze.c

does not affect UNKNOWN-type literals or Params.  This fixes the recent
complaint about count('x') being broken, and improves consistency in
a few other respects too.

proposal for eventually deprecating OIDs on user tables that I posted
earlier to pgsql-hackers. pg_dump now always specifies WITH OIDS or
WITHOUT OIDS when dumping a table. The documentation has been updated.

Neil Conway

$Header: -> $PostgreSQL Changes ...

tree for CYCLE option; don't assume zeros are invalid values for sequence
fields other than increment_by; don't reset cache_value when not told to;
simplify code for testing whether to apply defaults.

large objects.  Dump all these in pg_dump; also add code to pg_dump
user-defined conversions.  Make psql's large object code rely on
the backend for inserting/deleting LOB comments, instead of trying to
hack pg_description directly.  Documentation and regression tests added.

Christopher Kings-Lynne, code reviewed by Tom

pghackers proposal of 8-Nov.  All the existing cross-type comparison
operators (int2/int4/int8 and float4/float8) have appropriate support.
The original proposal of storing the right-hand-side datatype as part of
the primary key for pg_amop and pg_amproc got modified a bit in the event;
it is easier to store zero as the 'default' case and only store a nonzero
when the operator is actually cross-type.  Along the way, remove the
long-since-defunct bigbox_ops operator class.

Remove the 'strategy map' code, which was a large amount of mechanism
that no longer had any use except reverse-mapping from procedure OID to
strategy number.  Passing the strategy number to the index AM in the
first place is simpler and faster.
This is a preliminary step in planned support for cross-datatype index
operations.  I'm committing it now since the ScanKeyEntryInitialize()
API change touches quite a lot of files, and I want to commit those
changes before the tree drifts under me.

like the next higher one.

regression=# select 1 from tenk1 ta cross join tenk1 tb for update;
ERROR:  no relation entry for relid 3

7.3 said "SELECT FOR UPDATE cannot be applied to a join", which was better
but still wrong, considering that 7.2 took the query just fine.  Fix by
making transformForUpdate() ignore JOIN and other special RTE types,
rather than trying to mark them FOR UPDATE.  The actual error message now
only appears if you explicitly name the join in FOR UPDATE.

behavior reported by Martin Marques.