that turn into CASE expressions.  They evaluate their arguments at most
once.  Patch by Kris Jurka, review and (very light) editorializing by me.

< * Disallow DROP COLUMN on a column that is part of a multi-column index
> * Require DROP COLUMN CASCADE for a column that is part of a multi-column index

a bad choice between sorted and hashed aggregation.

the outer query.  (The implementation is a bit klugy, but it would take
nontrivial restructuring to make it nicer, which this is probably not
worth.)  This avoids unnecessary sort steps in examples like
SELECT foo,count(*) FROM (SELECT ... ORDER BY foo,bar) sub GROUP BY foo
which means there is now a reasonable technique for controlling the
order of inputs to custom aggregates, even in the grouping case.

> * Disallow DROP COLUMN on a column that is part of a multi-column index

ps for multiple postmasters, for Kevin Brown.

same type in a rule.  Per bug report from Pavel Hanak.

> * Allow incremental backups

> * Add schema option to createlang

Change was actually made in a previous commit.

- More work on Informix compatibility.

> * Cache last known per-tuple offsets to speed long tuple access

SIGPIPE disabled, and does not need to waste two syscalls per I/O on it.

an ALTER TABLE ADD COLUMN command.  Per bug #896.

the table(s) modified by the original query would get checked for the
type of write permission needed by a rule query.

of the containing query (which really can only happen in a rule context).
Per example from Brandon Craig Rhodes.  Also, make the error message
more specific for the similar case with sub-select in FROM.  The revised
coding should be easier to adapt to SQL99's LATERAL(), when we get around
to supporting that.

from Greg Stark.  Also, twiddle the FuncCall case to not scribble on
the input structure, which was the proximate cause of the problem.
Someday we ought to fix things so that transformExpr() isn't called
on already-transformed trees ...

- Started with an Informix compatibility option.

> =================================================================
> User interface proposal for multi-row function targetlist entries
> =================================================================
> 1. Only one targetlist entry may return a set.
> 2. Each targetlist item (other than the set returning one) is
>    repeated for each item in the returned set.
>

Having gotten no objections (actually, no response at all), I can only
assume no one had heartburn with this change. The attached patch covers
the first of the two proposals, i.e. restricting the target list to only
one set returning function.

Joe Conway

makes a few editorial changes to the documentation.


Neil Conway

longer works -- IncrHeapAccessStat() didn't actually *do* anything
anymore, so no reason to keep it around AFAICS. I also fixed a
grammatical error in a comment.


Neil Conway

> > comma).
>
> OK. But the documentation implies there is a comma, so it should probably
> get chenged then.

Yes, it should. (attached)

[ Backpatched to 7.3.X too.]

Rod Taylor

in one of the earth functions so that latitude and longitude to
cartesian coordinates conversion will be more accurrate. (Previously
a text string was built to provide as input which limited the accuracy
to the number of digits printed.)

The new functions were included in a recent patch to contrib/cube that has not
as yet been accepted as of yet.

I also added check constraints to the domain 'earth' since they are now
working in 7.4.

Bruno Wolff III

directly from float8 values. (As opposed to converting the values to
strings
and then parsing the strings.)
The functions are:
cube(float8) returns cube
cube(float8,float8) returns cube
cube(cube,float8) returns cube
cube(cube,float8,float8) returns cube

Bruno Wolff III