known problem with failure to respond to 'pg_ctl stop -m fast', and
probable problems if SIGINT or SIGTERM arrives while processing a
SIGUSR2 interrupt that arrived while waiting for a new client query.
< o Allow CLUSTER to cluster all tables (Alvaro Herrera)
> o -Allow CLUSTER to cluster all tables (Alvaro Herrera)
243c243
< * Allow pg_dump to dump a specific schema (Neil Conway)
> * -Allow pg_dump to dump a specific schema (Neil Conway)
398c398
< * Make IN/NOT IN have similar performance to EXISTS/NOT EXISTS (Tom)
> * -Make IN/NOT IN have similar performance to EXISTS/NOT EXISTS (Tom)
> o -Add ALTER TABLE tab SET WITHOUT OIDS (Rod)
> o -Allow CLUSTER to cluster all tables (Alvaro Herrera)
> * -Allow pg_dump to dump a specific schema (Neil Conway)
> * -Make IN/NOT IN have similar performance to EXISTS/NOT EXISTS (Tom)
> * Rod is Rod Taylor <pg@rbt.ca)>
in the case where the node immediately above the scan is a Hash, Sort,
or Material node. In these cases it's better to do the projection
so that we don't store unneeded columns in the hash/sort/materialize
table. Per discussion a few days ago with Anagh Lal.
< * 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
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.
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 ...
> =================================================================
> 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
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