See subject.  If we want to force an initdb to ensure the recent
information_schema updates take effect, we have to do it before beta5
release, I think.

I'm inclined to do it --- I don't get the sense that too many people
have loaded large databases into 7.4 beta installations --- but if
anyone wants to object now is the time.

			regards, tom lane

Mon, 20 Oct 2003 17:35:20 -0400
Tom Lane <tgl@sss.pgh.pa.us>
So, are we going to bump catversion for beta5, or not?
Tom Lane writes:

> I'm inclined to do it --- I don't get the sense that too many people
> have loaded large databases into 7.4 beta installations --- but if
> anyone wants to object now is the time.

Oops, I already did it.  But if someone objects, it's an easy change back.

-- 
Peter Eisentraut   peter_e@gmx.net


Tue, 21 Oct 2003 00:09:16 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: So, are we going to bump catversion for beta5, or not?
Peter Eisentraut wrote:
> Tom Lane writes:
> 
> > I'm inclined to do it --- I don't get the sense that too many people
> > have loaded large databases into 7.4 beta installations --- but if
> > anyone wants to object now is the time.
> 
> Oops, I already did it.  But if someone objects, it's an easy change back.

I guess my question would be how many people are using information
schemas vs. have loaded databases they don't want to reload.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Mon, 20 Oct 2003 23:16:14 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: So, are we going to bump catversion for beta5, or not?


On Mon, 20 Oct 2003, Bruce Momjian wrote:

> Peter Eisentraut wrote:
> > Tom Lane writes:
> >
> > > I'm inclined to do it --- I don't get the sense that too many people
> > > have loaded large databases into 7.4 beta installations --- but if
> > > anyone wants to object now is the time.
> >
> > Oops, I already did it.  But if someone objects, it's an easy change back.
>
> I guess my question would be how many people are using information
> schemas vs. have loaded databases they don't want to reload.

We are still in beta, not RC ... why is this even an issue?

Tue, 21 Oct 2003 01:16:55 -0300 (ADT)
"Marc G. Fournier" <scrappy@postgresql.org>
Re: So, are we going to bump catversion for beta5, or not?
"Marc G. Fournier" <scrappy@postgresql.org> writes:
> On Mon, 20 Oct 2003, Bruce Momjian wrote:
>> I guess my question would be how many people are using information
>> schemas vs. have loaded databases they don't want to reload.

> We are still in beta, not RC ... why is this even an issue?

Given that no one's squawked, I think it isn't...

			regards, tom lane

Tue, 21 Oct 2003 00:37:00 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: So, are we going to bump catversion for beta5, or not? 
Tom Lane wrote:
> "Marc G. Fournier" <scrappy@postgresql.org> writes:
> > On Mon, 20 Oct 2003, Bruce Momjian wrote:
> >> I guess my question would be how many people are using information
> >> schemas vs. have loaded databases they don't want to reload.
> 
> > We are still in beta, not RC ... why is this even an issue?
> 
> Given that no one's squawked, I think it isn't...

We try to limit initdb in late betas --- that has always been our
process.  I don't have any problem with the initdb, though.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 21 Oct 2003 11:55:21 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: So, are we going to bump catversion for beta5, or not?
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> We try to limit initdb in late betas --- that has always been our
> process.  I don't have any problem with the initdb, though.

We now have another reason to, which is Chris K-L's point about
unqualified names in the various SQL-language built-in functions.
I am about to commit that fix (with another catversion bump for
good measure...)

			regards, tom lane

Tue, 21 Oct 2003 12:13:50 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: So, are we going to bump catversion for beta5, or not? 
Tom Lane writes:

> We now have another reason to, which is Chris K-L's point about
> unqualified names in the various SQL-language built-in functions.
> I am about to commit that fix (with another catversion bump for
> good measure...)

Oh dear.  We really need this function-specific schema path that the SQL
standard seems to talk about.

-- 
Peter Eisentraut   peter_e@gmx.net


Tue, 21 Oct 2003 18:23:03 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: So, are we going to bump catversion for beta5, or not?
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> We now have another reason to, which is Chris K-L's point about
>> unqualified names in the various SQL-language built-in functions.
>> I am about to commit that fix (with another catversion bump for
>> good measure...)

> Oh dear.  We really need this function-specific schema path that the SQL
> standard seems to talk about.

Possibly.  It's not happening for 7.4 though ...

			regards, tom lane

Tue, 21 Oct 2003 12:29:41 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: So, are we going to bump catversion for beta5, or not? 
>>We now have another reason to, which is Chris K-L's point about
>>unqualified names in the various SQL-language built-in functions.
>>I am about to commit that fix (with another catversion bump for
>>good measure...)
> 
> 
> Oh dear.  We really need this function-specific schema path that the SQL
> standard seems to talk about.

What's that?  How would it help?

Chris



Wed, 22 Oct 2003 09:32:55 +0800
Christopher Kings-Lynne <chriskl@familyhealth.com.au>
Re: So, are we going to bump catversion for beta5, or not?
Christopher Kings-Lynne writes:

> > Oh dear.  We really need this function-specific schema path that the SQL
> > standard seems to talk about.
>
> What's that?  How would it help?

The idea is that you give each function its own schema search path at
creation time, and that path applies to that function for the rest of its
life.  Then that function would be immune to schema path changes later on.

-- 
Peter Eisentraut   peter_e@gmx.net


Wed, 22 Oct 2003 07:55:28 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: So, are we going to bump catversion for beta5, or not?
On Wednesday 22 October 2003 06:55, Peter Eisentraut wrote:
> Christopher Kings-Lynne writes:
> > > Oh dear.  We really need this function-specific schema path that the
> > > SQL standard seems to talk about.
> >
> > What's that?  How would it help?
>
> The idea is that you give each function its own schema search path at
> creation time, and that path applies to that function for the rest of its
> life.  Then that function would be immune to schema path changes later on.

But surely that would mean I couldn't do:

CREATE VIEW accts_schema.my_users AS
SELECT * FROM all_users WHERE dept='ACCTS';

CREATE VIEW sales_schema.my_users AS
SELECT * FROM all_users WHERE dept='SALES';

CREATE FUNCTION num_dept_users() RETURNS int4 AS '
SELECT count(*) FROM my_users;
' LANGUAGE SQL;

If SELECT num_dept_users() gives a different result to SELECT count(*) FROM 
my_users that can't be desirable.
-- 
  Richard Huxton
  Archonet Ltd

Wed, 22 Oct 2003 11:55:55 +0100
Richard Huxton <dev@archonet.com>
Re: So, are we going to bump catversion for beta5, or not?
Richard Huxton <dev@archonet.com> writes:
> On Wednesday 22 October 2003 06:55, Peter Eisentraut wrote:
>> The idea is that you give each function its own schema search path at
>> creation time, and that path applies to that function for the rest of its
>> life.  Then that function would be immune to schema path changes later on.

> But surely that would mean I couldn't do ...

Certainly you can invent scenarios where letting the search path vary
from call to call is useful, but the question is which behavior is
*more* useful.  I think it's becoming clear that having a predictable
search path is usually what a function author will want.

It would probably be a good idea to allow the function's search path to
be explicitly specified as a clause of CREATE FUNCTION (otherwise it
will be a headache for pg_dump).  So we could allow both viewpoints,
if there is a way to explicitly say "don't force any search path".
Perhaps specifying an empty path could mean that.  But I think the
default should be to adopt the current search path (at the time of
CREATE FUNCTION) as the function's permanent path.

			regards, tom lane

Wed, 22 Oct 2003 09:28:42 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: So, are we going to bump catversion for beta5, or not? 
On Wed, 2003-10-22 at 09:28, Tom Lane wrote:
> Richard Huxton <dev@archonet.com> writes:
> > On Wednesday 22 October 2003 06:55, Peter Eisentraut wrote:
> >> The idea is that you give each function its own schema search path at
> >> creation time, and that path applies to that function for the rest of its
> >> life.  Then that function would be immune to schema path changes later on.
> 
> > But surely that would mean I couldn't do ...
> 
> Certainly you can invent scenarios where letting the search path vary
> from call to call is useful, but the question is which behavior is
> *more* useful.  I think it's becoming clear that having a predictable
> search path is usually what a function author will want.
> 
> It would probably be a good idea to allow the function's search path to
> be explicitly specified as a clause of CREATE FUNCTION (otherwise it
> will be a headache for pg_dump).  So we could allow both viewpoints,
> if there is a way to explicitly say "don't force any search path".
> Perhaps specifying an empty path could mean that.  But I think the
> default should be to adopt the current search path (at the time of
> CREATE FUNCTION) as the function's permanent path.
> 

Well, you certainly need a way to do both, since IMHO the most useful
would be to have the search path be equal to the callers search path, at
least in the case of SECURITY INVOKER. YMMV.

Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL


22 Oct 2003 10:01:41 -0400
Robert Treat <xzilla@users.sourceforge.net>
Re: So, are we going to bump catversion for beta5, or not?
Tom Lane wrote:
> Richard Huxton <dev@archonet.com> writes:
> > On Wednesday 22 October 2003 06:55, Peter Eisentraut wrote:
> >> The idea is that you give each function its own schema search path at
> >> creation time, and that path applies to that function for the rest of its
> >> life.  Then that function would be immune to schema path changes later on.
> 
> > But surely that would mean I couldn't do ...
> 
> Certainly you can invent scenarios where letting the search path vary
> from call to call is useful, but the question is which behavior is
> *more* useful.  I think it's becoming clear that having a predictable
> search path is usually what a function author will want.
> 
> It would probably be a good idea to allow the function's search path to
> be explicitly specified as a clause of CREATE FUNCTION (otherwise it
> will be a headache for pg_dump).  So we could allow both viewpoints,
> if there is a way to explicitly say "don't force any search path".
> Perhaps specifying an empty path could mean that.  But I think the
> default should be to adopt the current search path (at the time of
> CREATE FUNCTION) as the function's permanent path.

Added to TODO:

	* Allow functions to have a search path specified at creation time

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Wed, 22 Oct 2003 13:14:59 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: So, are we going to bump catversion for beta5, or not?
On Wed, 22 Oct 2003, Tom Lane wrote:

> Richard Huxton <dev@archonet.com> writes:
> > On Wednesday 22 October 2003 06:55, Peter Eisentraut wrote:
> >> The idea is that you give each function its own schema search path at
> >> creation time, and that path applies to that function for the rest of its
> >> life.  Then that function would be immune to schema path changes later on.
> 
> > But surely that would mean I couldn't do ...
> 
> Certainly you can invent scenarios where letting the search path vary
> from call to call is useful, but the question is which behavior is
> *more* useful.  I think it's becoming clear that having a predictable
> search path is usually what a function author will want.
> 
> It would probably be a good idea to allow the function's search path to
> be explicitly specified as a clause of CREATE FUNCTION (otherwise it
> will be a headache for pg_dump).  So we could allow both viewpoints,
> if there is a way to explicitly say "don't force any search path".
> Perhaps specifying an empty path could mean that.  But I think the
> default should be to adopt the current search path (at the time of
> CREATE FUNCTION) as the function's permanent path.

It might be nice to have an alter function capability that could change 
the search path at a later date should one add schema etc... later on.


Wed, 22 Oct 2003 13:12:56 -0600 (MDT)
"scott.marlowe" <scott.marlowe@ihs.com>
Re: So, are we going to bump catversion for beta5, or not?
On Wednesday 22 October 2003 20:12, scott.marlowe wrote:
> On Wed, 22 Oct 2003, Tom Lane wrote:
> > It would probably be a good idea to allow the function's search path to
> > be explicitly specified as a clause of CREATE FUNCTION (otherwise it
> > will be a headache for pg_dump).  So we could allow both viewpoints,
> > if there is a way to explicitly say "don't force any search path".
> > Perhaps specifying an empty path could mean that.  But I think the
> > default should be to adopt the current search path (at the time of
> > CREATE FUNCTION) as the function's permanent path.
>
> It might be nice to have an alter function capability that could change
> the search path at a later date should one add schema etc... later on.

If it's part of CREATE FUNCTION then presumably CREATE OR REPLACE FUNCTION 
would let you do that (it's not changing the signature of the function, so I 
can't think why not).

-- 
  Richard Huxton
  Archonet Ltd

Thu, 23 Oct 2003 09:56:14 +0100
Richard Huxton <dev@archonet.com>
Re: So, are we going to bump catversion for beta5, or not?