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

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

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?

"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

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

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

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

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

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

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

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

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

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

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

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.

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