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.

Also applied patch from Lars Stenberg to make callable statements use the form
select * from func() when running against a 7.3 server instead of select func() to allow for set returning functions to be called.

 Modified Files:
 	jdbc/org/postgresql/errors.properties
 	jdbc/org/postgresql/core/Encoding.java
 	jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java

rid of the assumption that sizeof(Oid)==sizeof(int).  This is one small
step towards someday supporting 8-byte OIDs.  For the moment, it doesn't
do much except get rid of a lot of unsightly casts.

locParam lists can be converted to bitmapsets to speed updating.  Also,
replace 'locParam' with 'allParam', which contains all the paramIDs
relevant to the node (i.e., the union of extParam and locParam); this
saves a step during SetChangedParamList() without costing anything
elsewhere.

Instead of Lists of integers, we now store variable-length bitmap sets.
This should be faster as well as less error-prone.

Instead of grovelling through pg_class to find them, make use of the
handy dandy dependency mechanism: just delete everything that depends
on our temp schema.  Unlike the pg_class scan, the dependency mechanism
is smart enough to delete things in an order that doesn't fall foul of
any dependency restrictions.  Fixes problem reported by David Heggie:
a temp table with a serial column may cause a backend FATAL exit at
shutdown time, if it chances to try to delete the temp sequence first.

referenced from a subquery.  Per example from Stefanos Harhalakis.

expression accepted by the regex operators, per discussion yesterday.

Along the way, reduce deadlock_timeout from PGC_POSTMASTER to PGC_SIGHUP
category.  It is probably best to insist that all backends share the same
setting, but that doesn't mean it has to be frozen at startup.

per report from Ian Harding.

construction 'SETOF type[]' which for some reason was previously
overlooked (you'd have to name the array type directly to make it work).

(extracted from Tcl 8.4.1 release, as Henry still hasn't got round to
making it a separate library).  This solves a performance problem for
multibyte, as well as upgrading our regexp support to match recent Tcl
and nearly match recent Perl.

and the other fixes a NPE in Statement.toString() under some circumstances.
The second patch was originally submitted by Oliver Jowett and updated by Kris

so that rows can be fetched incrementally.  This is enabled by using
setFetchSize()

and convert pull_agg_clause() into count_agg_clause(), which is a more
efficient way of doing what it's really being used for.

speeds up some useful real-world cases like
SELECT x, COUNT(*) FROM t GROUP BY x HAVING COUNT(*) > 100.