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

spec, which will also make alter sequence a touch easier.

sequence.c  init_params() will check for settings which have been
defined twice, and complain.

Rod Taylor

takes two parameters, an OID x and an integer y, and returns "true" with
probability 1/y (the OID argument is ignored). This can be useful -- for
example, it can be used to select a random sampling of the rows in a
table (which is what the "random" regression test uses it for).

This patch removes that function, because it was old and messy. The old
function had the following problems:

- it was undocumented

- it was poorly named

- it was designed to workaround an optimizer bug that no longer exists
(the OID argument is to ensure that the optimizer won't optimize away
calls to the function; AFAIK marking the function as 'volatile' suffices
nowadays)

- it used a different random-number generation technique than the other
PSRNG-related functions in the backend do (it called random() like they
do, but it had its own logic for setting a set and deciding when to
reseed the RNG).

Ok, this patch removes oidrand(), oidsrand(), and userfntest(), and
improves the SGML docs a little bit (un-commenting the setseed()
documentation).

Neil Conway

On Wed, 2003-01-08 at 21:59, Christopher Kings-Lynne wrote:
> I agree.  I want to remove OIDs from heaps of our tables when we go to 7.3.
> I'd rather not have to do it in the dump due to down time.


Rod Taylor <rbt@rbt.ca>

CHECK constraints.

There are apparently no other types of constraint in pg_constraint, so
now all bases are covered.  Also, this patch assumes that consrc for a
CHECK constraint is always bracketed so that it's not necessary to add
extra brackets.

Christopher Kings-Lynne

> 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.

It compiles cleanly, and passes all regression tests. If there are no
objections, please apply.

Any suggestions on where this should be documented (other than maybe sql-select)?

Thanks,

Joe

p.s. Here's what the previous example now looks like:
CREATE TABLE bar(f1 int, f2 text, f3 int);
INSERT INTO bar VALUES(1, 'Hello', 42);
INSERT INTO bar VALUES(2, 'Happy', 45);

CREATE TABLE foo(a int, b text);
INSERT INTO foo VALUES(42, 'World');
INSERT INTO foo VALUES(42, 'Everyone');
INSERT INTO foo VALUES(45, 'Birthday');
INSERT INTO foo VALUES(45, 'New Year');

CREATE TABLE foo2(a int, b text);
INSERT INTO foo2 VALUES(42, '!!!!');
INSERT INTO foo2 VALUES(42, '????');
INSERT INTO foo2 VALUES(42, '####');
INSERT INTO foo2 VALUES(45, '$$$$');

CREATE OR REPLACE FUNCTION getfoo(int) RETURNS SETOF text AS '
   SELECT b FROM foo WHERE a = $1
' language 'sql';

CREATE OR REPLACE FUNCTION getfoo2(int) RETURNS SETOF text AS '
   SELECT b FROM foo2 WHERE a = $1
' language 'sql';

regression=# SELECT f1, f2, getfoo(f3) AS f4 FROM bar;
  f1 |  f2   |    f4
----+-------+----------
   1 | Hello | World
   1 | Hello | Everyone
   2 | Happy | Birthday
   2 | Happy | New Year
(4 rows)

regression=# SELECT f1, f2, getfoo(f3) AS f4, getfoo2(f3) AS f5 FROM bar;
ERROR:  Only one target list entry may return a set result


Joe Conway

> I don't care what you use for short options if all useful ones are taken.
> But the long option should be --schema.

Ok, fair enough: a revised patch is attached that uses the '-n' short
option and the '--schema' long option.

Neil Conway

>
> > I already posted a one-line patch to implement this, but it doesn't
> > seem to hve come through to the list. Here it is inline, instead of as
> > an attachment:
>
> We need this to work without readline as well.  (Of course there won't be
> any history, but it needs to compile.)

<blush> Even after slogging my way through the nesting #ifdefs for readline
and win32, I forgot! Let's make that a three line patch, then.

Ross J. Reedstrom

 Modified Files:
 	jdbc/org/postgresql/errors_zh_TW.properties

< * Fix SELECT ... INTO and CREATE TABLE AS to have appopriate OID column

> * -Get faster regex() code from Henry Spencer <henry@zoo.utoronto.ca>

Patch to makefile to clean up some of the output

 Modified Files:
 	jdbc/Makefile jdbc/org/postgresql/errors.properties
 	jdbc/org/postgresql/errors_de.properties

targetlist of a set-operation tree.  I'm not sure that this solution
will really stand the test of time --- perhaps we need to make a special
RTE for such vars to refer to.  But this quick hack fixes Brandon Craig
Rhodes' complaint of 10-Feb-02 about EXCEPT in CREATE RULE, while not
changing any behavior in the better-tested cases where leftmostRTI is
one anyway.

constraints appearing in outer-join qualification clauses are restricted
as to when and where they can be pushed down.  Add regression test
to catch future errors in this area.

codes, per discussion from last March.  parse.h should now be included
*only* by gram.y, scan.l, keywords.c, parser.c.  This prevents surprising
misbehavior after seemingly-trivial grammar adjustments.

because there are WHERE clauses that will reject the null-extended rows.
Per suggestion from Brandon Craig Rhodes, 19-Nov-02.