mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-25 02:57:19 +02:00
7818 lines
358 KiB
Plaintext
7818 lines
358 KiB
Plaintext
From ronz@ravensfield.com Tue May 22 17:35:37 2001
|
||
Return-path: <ronz@ravensfield.com>
|
||
Received: from carp.ravensfield.com ([209.41.227.126])
|
||
by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f4MLZaQ17913
|
||
for <pgman@candle.pha.pa.us>; Tue, 22 May 2001 17:35:37 -0400 (EDT)
|
||
Received: from coho.ravensfield.com (coho [209.41.227.117])
|
||
by carp.ravensfield.com (Postfix) with SMTP
|
||
id 5C2A9800D; Tue, 22 May 2001 16:46:38 -0500 (EST)
|
||
Content-Type: text/plain;
|
||
charset="iso-8859-1"
|
||
From: Andrew Rawnsley <ronz@ravensfield.com>
|
||
Organization: Ravensfield Geographic
|
||
To: Bruce Momjian <pgman@candle.pha.pa.us>
|
||
Subject: Re: [GENERAL] Queries across multiple databases (was: SELECT from a table in another database).
|
||
Date: Tue, 22 May 2001 17:37:25 -0400
|
||
X-Mailer: KMail [version 1.2]
|
||
cc: Tom Lane <tgl@sss.pgh.pa.us>
|
||
References: <200105220437.f4M4bUA00539@candle.pha.pa.us>
|
||
In-Reply-To: <200105220437.f4M4bUA00539@candle.pha.pa.us>
|
||
MIME-Version: 1.0
|
||
Message-ID: <01052217372504.01367@coho.ravensfield.com>
|
||
Content-Transfer-Encoding: 8bit
|
||
Status: ORr
|
||
|
||
On Tuesday 22 May 2001 12:37am, Bruce Momjian wrote:
|
||
> Can you send me a little sample of SCHEMA use?
|
||
|
||
Pardon if this is more long-winded or tangental than you are looking for...
|
||
|
||
What may beconfusing many people (not excluding myself from time to time) is
|
||
that cross-schema queries may have nothing to do with cross-database queries,
|
||
which is an entirely different kettle of trout.... SCHEMAs as used by at
|
||
least by Oracle and Sybase are nothing more than users/object owners (I have
|
||
no experience with DB2 or Informix, or anything more exotic than that).
|
||
|
||
Just off the top of my head, what would satisfy most people would be to be
|
||
able to refer to objects as OWNER.OBJECT, with owner being 'within' the
|
||
database (i.e. DATABASE.OWNER.OBJECT, which is how Sybase does it. Oracle has
|
||
no 'database' parallel like that). Whether you do it Oracle-fashion and use
|
||
the term SCHEMA for owner pretty universally or Sybase fashion and just pay
|
||
lip service to the word doesn't really matter (unless there is a standards
|
||
compliance issue).
|
||
|
||
As to creating schemas...In Oracle you have to execute the CREATE SCHEMA
|
||
AUTHORIZATION <user> while logged in as that user before you can add objects
|
||
under that user's ownership. While it seems trivial, if you have a situation
|
||
where you do not want to grant a user session rights, you have to grant them
|
||
session rights, log in as them, execute CREATE SCHEMA..., then revoke the
|
||
session rights. Bah. A table created by user X in schema Y is also owned by
|
||
user Y, and its user Y that has to have many of the object rights to create
|
||
that table.
|
||
|
||
In Sybase, its essentially the same except the only real use for the CREATE
|
||
SCHEMA command is for compliance and to group some DDL commands together.
|
||
Other than that, Sybase always refers to schemas as owners. You don't have to
|
||
execute CREATE SCHEMA... to create objects - you just need the rights. I've
|
||
never used it at least - the only thing I see in it is eliminating the need
|
||
to type 'go' after every DDL command.
|
||
|
||
As for examples from Oracle space -
|
||
|
||
Here is a foreign key reference with delete triggers from a table in
|
||
schema/user PROJECT to tables in schemas/users SERVICES and WEBCAL:
|
||
|
||
CREATE TABLE PROJECT.tasks_users (
|
||
<EFBFBD> <20>event_id INTEGER REFERENCES WEBCAL.tasks(event_id) ON DELETE CASCADE,
|
||
<EFBFBD> <20>user_id VARCHAR2(25) REFERENCES SERVICES.users(user_id) ON DELETE CASCADE,
|
||
<EFBFBD> <20>confirmed CHAR(1),
|
||
<EFBFBD> <20>PRIMARY KEY (event_id,user_id)
|
||
);
|
||
|
||
A join between tables in would be
|
||
SELECT <20> A.SAMPLE_ID,
|
||
<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> A.CONCENTRATION,
|
||
<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> A.CASNO,
|
||
<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> B.PARAMETER,
|
||
<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> C.DESCRIPTION AS STYPE
|
||
<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> FROM HAI.RESULTS A, SAMPLETRACK.PARAMETERS B,
|
||
SAMPLETRACK.SAMPLE_TYPE C
|
||
<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> WHERE A.CASNO = B.CASNO AND A.SAMPLE_TYPE = B.SAMPLE_TYPE
|
||
|
||
In both Oracle and Sybase, all the objects are in the same 'database'
|
||
(instance in Oracle), as I assume they would be in Postgres. There is I
|
||
assume a name space issue - one should be able to create a FOO.BAR and a
|
||
BAR.BAR in the same database.
|
||
|
||
> I may be adding it to
|
||
> 7.2 inside the same code that maps temp table names to real tables.
|
||
>
|
||
|
||
Excellent! I see light at the end of the tunnel (I will say the Postgres
|
||
maintainers are among the most solidly competent around - one never has any
|
||
real doubts about the system's progress).
|
||
|
||
--
|
||
Regards,
|
||
|
||
Andrew Rawnsley
|
||
Ravensfield Digital Resource Group, Ltd.
|
||
(740) 587-0114
|
||
www.ravensfield.com
|
||
|
||
From reedstrm@rice.edu Wed May 23 10:59:42 2001
|
||
Return-path: <reedstrm@rice.edu>
|
||
Received: from ece.rice.edu (ece.rice.edu [128.42.4.34])
|
||
by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f4NExgQ05774
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 May 2001 10:59:42 -0400 (EDT)
|
||
Received: from wallace.ece.rice.edu (wallace.ece.rice.edu [128.42.12.154])
|
||
by ece.rice.edu (Postfix) with ESMTP id A419F68A0E
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 May 2001 09:59:36 -0500 (CDT)
|
||
Received: from reedstrm by wallace.ece.rice.edu with local (Exim 3.22 #1 (Debian))
|
||
id 152a41-0006E5-00
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 May 2001 09:56:41 -0500
|
||
Date: Wed, 23 May 2001 09:56:41 -0500
|
||
From: "Ross J. Reedstrom" <reedstrm@rice.edu>
|
||
To: Bruce Momjian <pgman@candle.pha.pa.us>
|
||
Subject: Re: [HACKERS] Re: [GENERAL] Re: [GENERAL] Queries across multiple databases ?(was: SELECT from a table in another database).
|
||
Message-ID: <20010523095641.D23741@rice.edu>
|
||
References: <004c01c0e214$ce6c4800$1001a8c0@archonet.com> <200105221131.f4MBVIc28574@candle.pha.pa.us>
|
||
MIME-Version: 1.0
|
||
Content-Type: text/plain; charset=us-ascii
|
||
Content-Disposition: inline
|
||
User-Agent: Mutt/1.3.17i
|
||
In-Reply-To: <200105221131.f4MBVIc28574@candle.pha.pa.us>; from pgman@candle.pha.pa.us on Tue, May 22, 2001 at 07:31:18AM -0400
|
||
Status: ORr
|
||
|
||
Bruce -
|
||
Around the first of the year, I started playing around with a schema
|
||
implementation. As you may recall, my first crack at changing file storage
|
||
names about a year ago was motivated by the need to avoid collisions
|
||
once schema were available.
|
||
|
||
Anyway, now that Vadim has removed a lot of the internal dependence
|
||
on relname for keeping track of relations, using the new relfinenode
|
||
many places relname used to be used, it seems to me that adding a
|
||
parallel schemaname to all the data structures that use relname isn't
|
||
as cumbersome as Peter might think. I hadn't tackled the relcache yet:
|
||
perhaps concatenating the schemaname and relname to use as the hash key
|
||
is the way to go for that.
|
||
|
||
Unfortunately, all that code is now 4 months old, and on my machine
|
||
at home. I has started with the rangetable entries, because hacked the
|
||
parser to allow 'SELECT * FROM schemaname.tablename' was easier than
|
||
'select schemaname.tablename.fieldname FROM', since the dot function
|
||
calling convention isn't allowed in the range list, while it is in the
|
||
target list.
|
||
|
||
I seem to recall tripping up on the query plan printer, of all things,
|
||
before other, paying work pushed it aside. I'll see if I can update that
|
||
code to the current tree, and send you something, if you'd like.
|
||
|
||
Ross
|
||
|
||
|
||
|
||
On Tue, May 22, 2001 at 07:31:18AM -0400, Bruce Momjian wrote:
|
||
> > > I'm not sure whether it is quite the way to do it, but I'd have a better
|
||
> > > time with things if I could span databases in a single request. Are
|
||
> > > there theoretical problems with spanning databases in a single query? Is
|
||
> > > it a feature of bad database design & implementation?
|
||
> >
|
||
> > I think the developers are planning full schema support for the relatively
|
||
> > near future (possibly even 7.2, but check the archives and see what's been
|
||
> > said). Although it looks easy to access a table from another database,
|
||
> > things can rapidly become more complicated as you start having to deal with
|
||
> > transactions, triggers, rules, constraints...
|
||
>
|
||
> Schema is on my radar screen for 7.2. I am waiting to do some research
|
||
> in what needs to be done, but my initial idea is to use the system cache
|
||
> to do namespace mapping, just like is done now for temp tables.
|
||
>
|
||
> --
|
||
> Bruce Momjian | http://candle.pha.pa.us
|
||
> pgman@candle.pha.pa.us | (610) 853-3000
|
||
> + If your life is a hard drive, | 830 Blythe Avenue
|
||
> + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
|
||
>
|
||
> ---------------------------(end of broadcast)---------------------------
|
||
> TIP 2: you can get off all lists at once with the unregister command
|
||
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
|
||
|
||
From pgsql-hackers-owner+M17793=candle.pha.pa.us=pgman@postgresql.org Fri Jan 18 19:40:47 2002
|
||
Return-path: <pgsql-hackers-owner+M17793=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0J0elU09208
|
||
for <pgman@candle.pha.pa.us>; Fri, 18 Jan 2002 19:40:47 -0500 (EST)
|
||
Received: (qmail 94886 invoked by alias); 19 Jan 2002 00:40:45 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 19 Jan 2002 00:40:45 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0J0TfV92793
|
||
for <pgsql-hackers@postgreSQL.org>; Fri, 18 Jan 2002 19:29:41 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0J0Th311096
|
||
for <pgsql-hackers@postgreSQL.org>; Fri, 18 Jan 2002 19:29:44 -0500 (EST)
|
||
To: pgsql-hackers@postgresql.org
|
||
Subject: [HACKERS] Schemas vs. PostQUEL: resolving qualified identifiers
|
||
Date: Fri, 18 Jan 2002 19:29:43 -0500
|
||
Message-ID: <11093.1011400183@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
I'm starting to think about how to do SQL-compatible schemas in Postgres.
|
||
|
||
One of the first issues that comes up is that Postgres has interpretations
|
||
of qualified (dotted) names that conflict with what the standard says to
|
||
do. This stuff is a hangover from Berkeley days and PostQUEL. Briefly,
|
||
since there are no schemas in PG, anytime we have a dotted name we know
|
||
that the first component *must* be a table name. Successive components are
|
||
then resolved as either column or function names applied to whatever we
|
||
have so far. For example,
|
||
|
||
a.b.c is equivalent to c(a.b) if c is a function
|
||
|
||
The equivalence works the other way too: you can write colname(tabname)
|
||
and it will be taken as tabname.colname (though this seems to work only
|
||
if tabname already has a rangetable entry).
|
||
|
||
This is not going to fly together with SQL92, which wants a.b.c to mean
|
||
schema a, table b, column c.
|
||
|
||
I believe we can resolve the conflict without breaking any cases that
|
||
are likely to be used much in practice. Here's my proposal:
|
||
|
||
First, I'd like to allow the notation "table.*" to be used as a function
|
||
argument, representing passing a whole-row value to a function (the
|
||
function's argument would be declared as the table rowtype). Presently
|
||
this is done by writing just the undecorated table name, but that is
|
||
ambiguous if the same name is also used as a column name in the query.
|
||
Also, we need this notation for use with qualified table names.
|
||
|
||
Having done that, we can resolve names appearing in expressions thus:
|
||
|
||
foo First try to resolve as unqualified column name;
|
||
if not found, try to resolve as unqualified table name
|
||
(in which case this is a whole-row value, equivalent
|
||
to foo.*).
|
||
|
||
foo.bar foo is an unqualified table name. Try first to resolve
|
||
bar as a column name of foo; if not found, try to resolve
|
||
bar as a function taking the rowtype of foo.
|
||
|
||
foo.bar.baz This refers to table bar in schema foo. baz is either
|
||
a column or function name, as above.
|
||
|
||
foo.bar.baz.quux Refers to table baz in schema bar in catalog foo.
|
||
quux is either a column or function name, as above.
|
||
|
||
foo.* foo is an unqualified table name; means whole-row value.
|
||
|
||
foo.bar.* Whole row of table bar in schema foo.
|
||
|
||
foo.bar.baz.* Whole row of table baz in schema bar in catalog foo.
|
||
|
||
The first two of these rules are the same as current behavior; the next
|
||
two are additions mandated by SQL92; the last three are a proposed
|
||
extension to allow unambiguous reference to whole-row values.
|
||
|
||
With these rules, we do not lose any functionality that we have now,
|
||
but some PostQUEL-ish constructs will need to be rewritten into an
|
||
equivalent form.
|
||
|
||
PostQUEL-isms that still work:
|
||
|
||
table.func equivalent to func(table.*)
|
||
|
||
func(table) equivalent to func(table.*), as long as table name
|
||
doesn't match any column name of the query
|
||
|
||
PostQUEL-isms that no longer work:
|
||
|
||
table.col.func Must rewrite as func(table.col)
|
||
|
||
table.func1.func2 Must rewrite as, eg, func2(func1(table.*))
|
||
|
||
While there are a couple of examples of the above two constructs in the
|
||
regression tests, I doubt they are used much in the real world.
|
||
|
||
Another PostQUEL-ism that I would like to remove is col(tab) to mean
|
||
tab.col; I'd prefer to restrict the function syntax to functions only.
|
||
We could continue to support this for unqualified table names, but
|
||
given the above rules it could not work for a qualified table name,
|
||
eg, col(schema.tab) would be misinterpreted. Again, it seems unlikely
|
||
that many people are using this, so we may as well try to regularize
|
||
the syntax as much as we can.
|
||
|
||
You may wonder why I'm still allowing the construction tab.func ---
|
||
why not get rid of that too? Well, mainly because I'd like to support
|
||
the Oracle-ish syntax for nextval: seqname.nextval. Together with the
|
||
desire not to break existing code unnecessarily, that seems a good enough
|
||
reason to leave it in.
|
||
|
||
Comments?
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 3: if posting/reading through Usenet, please send an appropriate
|
||
subscribe-nomail command to majordomo@postgresql.org so that your
|
||
message can get through to the mailing list cleanly
|
||
|
||
From pgsql-hackers-owner+M18054=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 14:15:06 2002
|
||
Return-path: <pgsql-hackers-owner+M18054=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0NJF5U00389
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 14:15:05 -0500 (EST)
|
||
Received: (qmail 74462 invoked by alias); 23 Jan 2002 19:13:45 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 19:13:45 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0NJ0Fl67761
|
||
for <pgsql-hackers@postgresql.org>; Wed, 23 Jan 2002 14:00:15 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0NJ00f04506;
|
||
Wed, 23 Jan 2002 14:00:01 -0500 (EST)
|
||
To: Fernando Nasser <fnasser@redhat.com>
|
||
cc: Zeugswetter Andreas SB SD <ZeugswetterA@spardat.at>,
|
||
pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] Schemas vs. PostQUEL: resolving qualified identifiers
|
||
In-Reply-To: <3C4EFD15.882B0785@redhat.com>
|
||
References: <46C15C39FEB2C44BA555E356FBCD6FA42128D9@m0114.s-mxs.net> <2521.1011798379@sss.pgh.pa.us> <3C4EFD15.882B0785@redhat.com>
|
||
Comments: In-reply-to Fernando Nasser <fnasser@redhat.com>
|
||
message dated "Wed, 23 Jan 2002 13:12:37 -0500"
|
||
Date: Wed, 23 Jan 2002 14:00:00 -0500
|
||
Message-ID: <4503.1011812400@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Fernando Nasser <fnasser@redhat.com> writes:
|
||
> Tom Lane wrote:
|
||
>> Okay, but then how will you refer unambiguously to the rowtype object?
|
||
|
||
> What about casting with the keyord ROW?
|
||
> func(ROW table)
|
||
> always refers to the row-type of table "table" even if there is
|
||
> a column called "table".
|
||
|
||
Strikes me as gratuituously different from the way everything else is
|
||
done. We have .* and %ROWTYPE and so forth, and they're all suffixes.
|
||
The closest analogy to your ROW syntax is CAST, but it doesn't alter the
|
||
initial interpretation of its argument.
|
||
|
||
I was toying with the notion of inventing some new notation like
|
||
table.**
|
||
I don't like double-asterisk much, but maybe there's some other symbol
|
||
we could use here?
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 4: Don't 'kill -9' the postmaster
|
||
|
||
From pgsql-hackers-owner+M18069=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 17:13:24 2002
|
||
Return-path: <pgsql-hackers-owner+M18069=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0NMDOU16966
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 17:13:24 -0500 (EST)
|
||
Received: (qmail 49292 invoked by alias); 23 Jan 2002 22:13:23 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 22:13:23 -0000
|
||
Received: from cygnus.com (runyon.sfbay.redhat.com [205.180.230.5] (may be forged))
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0NLvFl45904
|
||
for <pgsql-hackers@postgresql.org>; Wed, 23 Jan 2002 16:57:15 -0500 (EST)
|
||
(envelope-from fnasser@redhat.com)
|
||
Received: from redhat.com (totem.toronto.redhat.com [172.16.14.242])
|
||
by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id NAA18180;
|
||
Wed, 23 Jan 2002 13:57:09 -0800 (PST)
|
||
Message-ID: <3C4F31B4.C7C9B2D6@redhat.com>
|
||
Date: Wed, 23 Jan 2002 16:57:08 -0500
|
||
From: Fernando Nasser <fnasser@redhat.com>
|
||
Organization: Red Hat , Inc. - Toronto
|
||
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10smp i686)
|
||
X-Accept-Language: en
|
||
MIME-Version: 1.0
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Zeugswetter Andreas SB SD <ZeugswetterA@spardat.at>,
|
||
pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] Schemas vs. PostQUEL: resolving qualified identifiers
|
||
References: <46C15C39FEB2C44BA555E356FBCD6FA42128D9@m0114.s-mxs.net> <2521.1011798379@sss.pgh.pa.us> <3C4EFD15.882B0785@redhat.com> <4503.1011812400@sss.pgh.pa.us>
|
||
Content-Type: text/plain; charset=us-ascii
|
||
Content-Transfer-Encoding: 7bit
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Tom Lane wrote:
|
||
>
|
||
> Fernando Nasser <fnasser@redhat.com> writes:
|
||
> > Tom Lane wrote:
|
||
> >> Okay, but then how will you refer unambiguously to the rowtype object?
|
||
>
|
||
> > What about casting with the keyord ROW?
|
||
> > func(ROW table)
|
||
> > always refers to the row-type of table "table" even if there is
|
||
> > a column called "table".
|
||
>
|
||
> Strikes me as gratuituously different from the way everything else is
|
||
> done. We have .* and %ROWTYPE and so forth, and they're all suffixes.
|
||
> The closest analogy to your ROW syntax is CAST, but it doesn't alter the
|
||
> initial interpretation of its argument.
|
||
>
|
||
|
||
I didn't mean literally that way, I just wanted to add a keyword for
|
||
solving ambiguity (when there is one).
|
||
|
||
You are right, it should be:
|
||
|
||
func(table%ROWTYPE)
|
||
|
||
|
||
|
||
|
||
--
|
||
Fernando Nasser
|
||
Red Hat - Toronto E-Mail: fnasser@redhat.com
|
||
2323 Yonge Street, Suite #300
|
||
Toronto, Ontario M4P 2C9
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 5: Have you checked our extensive FAQ?
|
||
|
||
http://www.postgresql.org/users-lounge/docs/faq.html
|
||
|
||
From pgsql-hackers-owner+M17920=candle.pha.pa.us=pgman@postgresql.org Mon Jan 21 16:45:17 2002
|
||
Return-path: <pgsql-hackers-owner+M17920=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0LLjHU16235
|
||
for <pgman@candle.pha.pa.us>; Mon, 21 Jan 2002 16:45:17 -0500 (EST)
|
||
Received: (qmail 38745 invoked by alias); 21 Jan 2002 21:43:19 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 21 Jan 2002 21:43:19 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0LLTql30573
|
||
for <pgsql-hackers@postgreSQL.org>; Mon, 21 Jan 2002 16:29:53 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0LLTrf11384
|
||
for <pgsql-hackers@postgreSQL.org>; Mon, 21 Jan 2002 16:29:53 -0500 (EST)
|
||
To: pgsql-hackers@postgresql.org
|
||
Subject: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
Date: Mon, 21 Jan 2002 16:29:52 -0500
|
||
Message-ID: <11381.1011648592@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Continuing to think about implementing SQL schemas for 7.3 ...
|
||
|
||
Today's topic for discussion: which types of Postgres objects should
|
||
belong to schemas, and which ones should have other name scopes?
|
||
|
||
Relations (tables, indexes, views, sequences) clearly belong to schemas.
|
||
Since each relation has an associated datatype with the same name, it
|
||
seems that datatypes must belong to schemas as well. (Even if that
|
||
argument doesn't convince you, SQL99 says that user-defined datatypes
|
||
belong to schemas.) However the situation is murkier for other kinds of
|
||
objects.
|
||
|
||
Here are all the kinds of named objects that exist in Postgres today,
|
||
with some comments on whether they should belong to schemas or not:
|
||
|
||
relations Must be in schemas
|
||
types Must be in schemas
|
||
databases Databases contain schemas, not vice versa
|
||
users Users are cross-database, so not in schemas
|
||
groups User groups are cross-database, so not in schemas
|
||
languages Probably should not be in schemas
|
||
access methods Probably should not be in schemas
|
||
opclasses See below
|
||
operators See below
|
||
functions/procedures See below
|
||
aggregates Should treat same as regular functions
|
||
constraints See below
|
||
rules See below
|
||
triggers See below
|
||
NOTIFY conditions See below
|
||
|
||
Languages and access methods are not trivial to add to the system, so
|
||
there's not much risk of name conflicts, and no reason to make their name
|
||
scope less than global.
|
||
|
||
The situation is a lot murkier for operators and functions. These should
|
||
probably be treated alike, since operators are just syntactic sugar for
|
||
functions. I think the basic argument for making them schema-local is
|
||
that different users might conceivably want to define conflicting
|
||
functions or operators of the same name. Against that, however, there
|
||
are a number of reasons for wanting to keep these objects database-wide.
|
||
First off there are syntactic problems. Do you really want to write
|
||
A schemaname.+ B
|
||
to qualify an ambiguous "+" operator? Looks way too much like a syntax
|
||
error to me. Allowing this would probably turn a lot of simple syntax
|
||
errors into things that get past the grammar and end up producing truly
|
||
confusing error messages. Qualified function names also pose some
|
||
problems, not so much with
|
||
schemaname.function(args)
|
||
which seems reasonable, but with the Berkeley-derived syntax that allows
|
||
"foo.function" to mean "function(foo)" --- there's no way to squeeze a
|
||
schema-name for the function into that. (And you'll recall from my note
|
||
of the other day that we don't want to abandon this syntax entirely,
|
||
because people would like us to support "sequencename.nextval" for Oracle
|
||
compatibility.) Notice that we are not forced to make functions/operators
|
||
schema-local just because datatypes are, because overloading will save the
|
||
day. func(schema1.type1) and func(schema2.type1) are distinct functions
|
||
because the types are different, even if they live in the same function
|
||
namespace. Finally, SQL99 doesn't appear to think that operator and
|
||
function names are schema-local; though that may just be because it hasn't
|
||
got user-defined operators AFAICT.
|
||
|
||
I am leaning towards keeping functions/operators database-wide, but would
|
||
like to hear comments. Is there any real value in, eg, allowing different
|
||
users to define different "+" operators *on the same datatypes*?
|
||
|
||
Not sure about index opclasses. Given that datatype names are
|
||
schema-local, one can think of scenarios where two users define similar
|
||
datatypes and then try to use the same index opclass name for both.
|
||
But it seems pretty unlikely. I'd prefer to leave opclass names
|
||
database-wide for simplicity. Comments?
|
||
|
||
As for constraints, currently we only support table-level constraints,
|
||
and we do not enforce any uniqueness at all on their names; multiple
|
||
constraints for the same table can have the same name (and if so, ALTER
|
||
TABLE DROP CONSTRAINT drops all matching names). SQL92 requires named
|
||
constraints to have names that are unique within their schema, which is
|
||
okay for standalone assertions (which we haven't got) but seems quite
|
||
unnecessary for constraints attached to tables. And what's really odd,
|
||
it appears to allow a table constraint to belong to a different schema
|
||
than the table it is on! This is pretty bogus. I'd prefer to ignore the
|
||
part of the spec that says that table constraint names can be qualified
|
||
names, and either keep our existing behavior or require constraint names
|
||
to be unique per-table. Thoughts?
|
||
|
||
Rewrite rules are currently required to have a name unique within their
|
||
database. We clearly don't want that to still be true in the schema
|
||
environment. Personally I would like to make rules' names unique only
|
||
among rules on the same table (like we handle triggers). That would
|
||
mean an incompatible change in the syntax of DROP RULE: it'd have to
|
||
become DROP RULE rule ON table, much like DROP TRIGGER. Is that okay?
|
||
If not, probably we must make rulenames local to schemas and say they
|
||
implicitly belong to the schema of the associated table.
|
||
|
||
Triggers are already handled as being named uniquely among the triggers
|
||
of the same table. This behavior is fine with me, and doesn't need to
|
||
be changed for schema support.
|
||
|
||
I can see some advantage to considering NOTIFY condition names to be local
|
||
to a schema, but I can also see risks of breaking existing applications.
|
||
Currently, "NOTIFY foo" will signal to "LISTEN foo" even if the two
|
||
processes belong to different users. With an implicit schema qualifier
|
||
attached to foo, very likely this would fail to work. Since NOTIFY names
|
||
aren't officially registered anywhere, the implicit qualifier would have
|
||
to correspond to the front schema of one's schema search path, and there'd
|
||
be no way for such processes to communicate if their search paths didn't
|
||
match. I think people would end up always qualifying NOTIFY names with
|
||
a single schema name, which means we might as well continue to consider
|
||
them global. On the other hand, if you assume that NOTIFY names are often
|
||
the names of tables, it'd make sense to allow them to be qualified. Any
|
||
thoughts on this?
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 4: Don't 'kill -9' the postmaster
|
||
|
||
From pgsql-hackers-owner+M17929=candle.pha.pa.us=pgman@postgresql.org Mon Jan 21 19:13:39 2002
|
||
Return-path: <pgsql-hackers-owner+M17929=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0M0DcU03335
|
||
for <pgman@candle.pha.pa.us>; Mon, 21 Jan 2002 19:13:38 -0500 (EST)
|
||
Received: (qmail 78739 invoked by alias); 22 Jan 2002 00:12:48 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 22 Jan 2002 00:12:48 -0000
|
||
Received: from corvette.mascari.com (dhcp065-024-158-068.columbus.rr.com [65.24.158.68])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0LNo9l76502
|
||
for <pgsql-hackers@postgresql.org>; Mon, 21 Jan 2002 18:50:09 -0500 (EST)
|
||
(envelope-from mascarm@mascari.com)
|
||
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
|
||
by corvette.mascari.com (8.9.3/8.9.3) with ESMTP id SAA26029
|
||
for <pgsql-hackers@postgresql.org>; Mon, 21 Jan 2002 18:45:34 -0500
|
||
Message-ID: <3C4CA81E.4D1D7BD9@mascari.com>
|
||
Date: Mon, 21 Jan 2002 18:45:34 -0500
|
||
From: Mike Mascari <mascarm@mascari.com>
|
||
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
|
||
X-Accept-Language: en
|
||
MIME-Version: 1.0
|
||
To: pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
References: <11381.1011648592@sss.pgh.pa.us>
|
||
Content-Type: text/plain; charset=us-ascii
|
||
Content-Transfer-Encoding: 7bit
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Tom Lane wrote:
|
||
>
|
||
> Continuing to think about implementing SQL schemas for 7.3 ...
|
||
>
|
||
> Today's topic for discussion: which types of Postgres objects should
|
||
> belong to schemas, and which ones should have other name scopes?
|
||
...
|
||
>
|
||
> I am leaning towards keeping functions/operators database-wide, but would
|
||
> like to hear comments. Is there any real value in, eg, allowing different
|
||
> users to define different "+" operators *on the same datatypes*?
|
||
|
||
With regard to functions, I believe they should be schema specific.
|
||
Oracle allows the creation of procedures/functions in specific schema.
|
||
User2 may then execute user1's function as:
|
||
|
||
EXECUTE user1.myfunction();
|
||
|
||
However, as you suggest, the fully qualified naming of functions gets
|
||
messy. So Oracle allows (and I think we would need) PUBLIC SYNONYMs.
|
||
This allows user1 to do:
|
||
|
||
CREATE TABLE employees(key integer, name VARCHAR(20));
|
||
|
||
CREATE SEQUENCE s;
|
||
|
||
CREATE PROCEDURE newemployee(n IN VARCHAR)
|
||
AS
|
||
BEGIN
|
||
INSERT INTO employees
|
||
SELECT s.nextval, n
|
||
FROM DUAL;
|
||
END;
|
||
/
|
||
|
||
GRANT INSERT ON employees TO user2;
|
||
GRANT EXECUTE ON newemployee TO user2;
|
||
CREATE PUBLIC SYNONYM newemployee FOR user1.newemployee;
|
||
|
||
Now, user2 just does:
|
||
|
||
EXECUTE newemployee(10);
|
||
|
||
|
||
In fact, with regard to the package discussion a while back, Oracle
|
||
allows this:
|
||
|
||
Database->Schema->Package->Procedure
|
||
|
||
and this:
|
||
|
||
Database->Schema->Procedure
|
||
|
||
and effectively this:
|
||
|
||
Database->Procedure via Database->PUBLIC Schema->Procedure
|
||
|
||
I really think that the main purpose of schemas is to prevent an
|
||
ill-informed or malicious user from engaging in unacceptable behavior.
|
||
By placing everything in schemas, it allows the Oracle DBA to have a
|
||
very fine-grained control over the ability of user1 to interfere with
|
||
user2. Before user1 above could pollute the global namespace, the dba
|
||
must have:
|
||
|
||
GRANT user1 CREATE PUBLIC SYNONYM
|
||
|
||
privilege, or created the synonym himself. This allows things like
|
||
pg_class to reside within their own schema, as well as all built-in
|
||
PostgreSQL functions. After the bootstrapping, PUBLIC SYNONYMs are
|
||
created for all of the system objects which should have global scope:
|
||
|
||
CREATE PUBLIC SYNONYM pg_class FOR system.pg_class;
|
||
CREATE PUBLIC SYNONYM abs(int) FOR system.abs(int);
|
||
|
||
One major benefit of Oracle is that the DBA, through the use of
|
||
STATEMENT privileges (i.e. GRANT CREATE TABLE to user1), resource
|
||
PROFILEs, and TABLESPACES can easily admin a database used by 20
|
||
different deparments and 1000 different users without the fear that one
|
||
might step on the other's toes. If the accounting department wants to
|
||
create an addtax() function, it shouldn't have to ask the receiving
|
||
deptartment to do so.
|
||
|
||
Just my thoughts,
|
||
|
||
Mike Mascari
|
||
mascarm@mascari.com
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 2: you can get off all lists at once with the unregister command
|
||
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
|
||
|
||
From pgsql-hackers-owner+M17928=candle.pha.pa.us=pgman@postgresql.org Mon Jan 21 19:13:39 2002
|
||
Return-path: <pgsql-hackers-owner+M17928=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0M0DcU03336
|
||
for <pgman@candle.pha.pa.us>; Mon, 21 Jan 2002 19:13:38 -0500 (EST)
|
||
Received: (qmail 78777 invoked by alias); 22 Jan 2002 00:12:50 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 22 Jan 2002 00:12:50 -0000
|
||
Received: from student.gvsu.edu ([148.61.7.124])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0LNxBl77018
|
||
for <pgsql-hackers@postgreSQL.org>; Mon, 21 Jan 2002 18:59:12 -0500 (EST)
|
||
(envelope-from peter_e@gmx.net)
|
||
Received: from [148.61.250.18] [148.61.250.18] by student.gvsu.edu
|
||
with Novonyx SMTP Server $Revision: 1.3 $; Mon, 21 Jan 2002 18:59:14 -0500 (EDT)
|
||
Date: Mon, 21 Jan 2002 19:01:13 -0500 (EST)
|
||
From: Peter Eisentraut <peter_e@gmx.net>
|
||
X-Sender: <peter@peter.localdomain>
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <11381.1011648592@sss.pgh.pa.us>
|
||
Message-ID: <Pine.LNX.4.30.0201211840260.687-100000@peter.localdomain>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Tom Lane writes:
|
||
|
||
> languages Probably should not be in schemas
|
||
> access methods Probably should not be in schemas
|
||
> opclasses See below
|
||
> operators See below
|
||
> functions/procedures See below
|
||
> aggregates Should treat same as regular functions
|
||
> constraints See below
|
||
> rules See below
|
||
> triggers See below
|
||
> NOTIFY conditions See below
|
||
|
||
Remember that a schema is a named representation of ownership, so anything
|
||
that can be owned must be in a schema. (Unless you want to invent a
|
||
parallel universe for a different kind of ownership, which would be
|
||
incredibly confusing.) Also remember that we wanted to use schemas as a
|
||
way to prevent unprivileged users from creating anything by default. So
|
||
it would be much simpler if "everything" were in a schema.
|
||
|
||
I wouldn't worry so much about the invocation syntax -- if you don't like
|
||
ugly don't make ugly. For instance, if you add a user-defined operator
|
||
you would probably either put it in the same schema with the rest of your
|
||
project or put it in some sort of a global or default schema (to be
|
||
determined) to make it available to the whole system, my assumption being
|
||
that either way you don't need to qualify the operator. But the important
|
||
thing is that you *could* make cross-schema operator calls, say during
|
||
development or testing.
|
||
|
||
Consequentially, I opine that all of the things listed above should be in
|
||
a schema. (Although I don't have a strong opinion about notifications,
|
||
yet.)
|
||
|
||
> namespace. Finally, SQL99 doesn't appear to think that operator and
|
||
> function names are schema-local; though that may just be because it hasn't
|
||
> got user-defined operators AFAICT.
|
||
|
||
Check clause 10.4 <routine invocation>: routine names are (optionally)
|
||
schema qualified like everything else.
|
||
|
||
> Rewrite rules are currently required to have a name unique within their
|
||
> database. We clearly don't want that to still be true in the schema
|
||
> environment. Personally I would like to make rules' names unique only
|
||
> among rules on the same table (like we handle triggers). That would
|
||
> mean an incompatible change in the syntax of DROP RULE: it'd have to
|
||
> become DROP RULE rule ON table, much like DROP TRIGGER. Is that okay?
|
||
> If not, probably we must make rulenames local to schemas and say they
|
||
> implicitly belong to the schema of the associated table.
|
||
|
||
I'd rather make the opposite change (make trigger names schema-global)
|
||
because that aligns with SQL99 and it would make more sense for overall
|
||
consistency (e.g., you can't have indexes with the same names on different
|
||
tables). The syntax change would also be backward compatible. I think
|
||
either way, schema-global or table-global namespace, can be argued to be
|
||
more useful or more confusion-prone, so I side with the standard on this
|
||
one.
|
||
|
||
--
|
||
Peter Eisentraut peter_e@gmx.net
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 3: if posting/reading through Usenet, please send an appropriate
|
||
subscribe-nomail command to majordomo@postgresql.org so that your
|
||
message can get through to the mailing list cleanly
|
||
|
||
From pgsql-hackers-owner+M17932=candle.pha.pa.us=pgman@postgresql.org Mon Jan 21 20:14:13 2002
|
||
Return-path: <pgsql-hackers-owner+M17932=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0M1ECU11565
|
||
for <pgman@candle.pha.pa.us>; Mon, 21 Jan 2002 20:14:12 -0500 (EST)
|
||
Received: (qmail 88800 invoked by alias); 22 Jan 2002 01:14:11 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 22 Jan 2002 01:14:11 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0M16kl87933
|
||
for <pgsql-hackers@postgreSQL.org>; Mon, 21 Jan 2002 20:06:47 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0M16Uf12242;
|
||
Mon, 21 Jan 2002 20:06:30 -0500 (EST)
|
||
To: Peter Eisentraut <peter_e@gmx.net>
|
||
cc: pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <Pine.LNX.4.30.0201211840260.687-100000@peter.localdomain>
|
||
References: <Pine.LNX.4.30.0201211840260.687-100000@peter.localdomain>
|
||
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
|
||
message dated "Mon, 21 Jan 2002 19:01:13 -0500"
|
||
Date: Mon, 21 Jan 2002 20:06:30 -0500
|
||
Message-ID: <12239.1011661590@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Peter Eisentraut <peter_e@gmx.net> writes:
|
||
> Remember that a schema is a named representation of ownership, so anything
|
||
> that can be owned must be in a schema. (Unless you want to invent a
|
||
> parallel universe for a different kind of ownership, which would be
|
||
> incredibly confusing.)
|
||
|
||
I don't buy that premise. It's true that SQL92 equates ownership of a
|
||
schema with ownership of the objects therein, but AFAICS we have no hope
|
||
of being forward-compatible with existing database setups (wherein there
|
||
can be multiple tables of different ownership all in a single namespace)
|
||
if we don't allow varying ownership within a schema. I think we can
|
||
arrange things so that we are upward compatible with both SQL92 and
|
||
the old way. Haven't worked out details yet though.
|
||
|
||
Have to run, more later.
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
|
||
|
||
From pgsql-hackers-owner+M17933=candle.pha.pa.us=pgman@postgresql.org Mon Jan 21 20:42:40 2002
|
||
Return-path: <pgsql-hackers-owner+M17933=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0M1geU12708
|
||
for <pgman@candle.pha.pa.us>; Mon, 21 Jan 2002 20:42:40 -0500 (EST)
|
||
Received: (qmail 92393 invoked by alias); 22 Jan 2002 01:42:38 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 22 Jan 2002 01:42:38 -0000
|
||
Received: from p566.codebydesign.com (cx950878-a.fed1.sdca.home.com [24.11.158.40])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0M1cZl91431
|
||
for <pgsql-hackers@postgresql.org>; Mon, 21 Jan 2002 20:38:35 -0500 (EST)
|
||
(envelope-from pharvey@codebydesign.com)
|
||
Received: from p12.codebydesign.com (p12.codebydesign.com [192.168.1.27])
|
||
by p566.codebydesign.com (8.11.1/8.11.1) with SMTP id g0M2mmt12179;
|
||
Mon, 21 Jan 2002 18:48:53 -0800
|
||
Content-Type: text/plain;
|
||
charset="iso-8859-1"
|
||
From: Peter Harvey <pharvey@codebydesign.com>
|
||
Organization: CodeByDesign
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
Date: Mon, 21 Jan 2002 17:39:05 -0800
|
||
X-Mailer: KMail [version 1.2]
|
||
cc: pgsql-hackers@postgresql.org
|
||
References: <Pine.LNX.4.30.0201211840260.687-100000@peter.localdomain> <12239.1011661590@sss.pgh.pa.us>
|
||
In-Reply-To: <12239.1011661590@sss.pgh.pa.us>
|
||
MIME-Version: 1.0
|
||
Message-ID: <02012117390500.02279@p12.codebydesign.com>
|
||
Content-Transfer-Encoding: 8bit
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
FYI: Applications like Data Architect would benefit from a consistent and
|
||
complete interface to the schema. For example; I found that we had to bypass
|
||
the DD views which exist (as I recall) because they did not give us all
|
||
information we needed. So we selected stuff from the system tables directly.
|
||
Yucky. Sorry I can not recall details but thought that I would mention this
|
||
here. The MySQL 'SHOW' statements seem to work pretty well and shields us
|
||
from changes to the system tables.
|
||
|
||
Peter
|
||
|
||
> I don't buy that premise. It's true that SQL92 equates ownership of a
|
||
> schema with ownership of the objects therein, but AFAICS we have no hope
|
||
> of being forward-compatible with existing database setups (wherein there
|
||
> can be multiple tables of different ownership all in a single namespace)
|
||
> if we don't allow varying ownership within a schema. I think we can
|
||
> arrange things so that we are upward compatible with both SQL92 and
|
||
> the old way. Haven't worked out details yet though.
|
||
>
|
||
> Have to run, more later.
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
|
||
|
||
From pgsql-hackers-owner+M17966=candle.pha.pa.us=pgman@postgresql.org Tue Jan 22 10:53:20 2002
|
||
Return-path: <pgsql-hackers-owner+M17966=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0MFrJU05739
|
||
for <pgman@candle.pha.pa.us>; Tue, 22 Jan 2002 10:53:20 -0500 (EST)
|
||
Received: (qmail 83537 invoked by alias); 22 Jan 2002 15:53:00 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 22 Jan 2002 15:53:00 -0000
|
||
Received: from cygnus.com (runyon.sfbay.redhat.com [205.180.230.5] (may be forged))
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0MFoql80523
|
||
for <pgsql-hackers@postgresql.org>; Tue, 22 Jan 2002 10:50:52 -0500 (EST)
|
||
(envelope-from fnasser@redhat.com)
|
||
Received: from redhat.com (rtl.sfbay.redhat.com [205.180.230.21])
|
||
by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id HAA09903;
|
||
Tue, 22 Jan 2002 07:50:43 -0800 (PST)
|
||
Message-ID: <3C4D8A39.FF79CDC4@redhat.com>
|
||
Date: Tue, 22 Jan 2002 10:50:17 -0500
|
||
From: Fernando Nasser <fnasser@redhat.com>
|
||
Organization: Red Hat Canada
|
||
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686)
|
||
X-Accept-Language: en
|
||
MIME-Version: 1.0
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
References: <Pine.LNX.4.30.0201211840260.687-100000@peter.localdomain> <12239.1011661590@sss.pgh.pa.us>
|
||
Content-Type: text/plain; charset=us-ascii
|
||
Content-Transfer-Encoding: 7bit
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Tom Lane wrote:
|
||
>
|
||
> Peter Eisentraut <peter_e@gmx.net> writes:
|
||
> > Remember that a schema is a named representation of ownership, so anything
|
||
> > that can be owned must be in a schema. (Unless you want to invent a
|
||
> > parallel universe for a different kind of ownership, which would be
|
||
> > incredibly confusing.)
|
||
>
|
||
> I don't buy that premise. It's true that SQL92 equates ownership of a
|
||
> schema with ownership of the objects therein, but AFAICS we have no hope
|
||
> of being forward-compatible with existing database setups (wherein there
|
||
> can be multiple tables of different ownership all in a single namespace)
|
||
> if we don't allow varying ownership within a schema. I think we can
|
||
> arrange things so that we are upward compatible with both SQL92 and
|
||
> the old way. Haven't worked out details yet though.
|
||
>
|
||
|
||
Peter is right. Schemas is just a practical way of creating things
|
||
under
|
||
the same authorization-id + crating a namespace so that different
|
||
authorization-ids can have objects with the same (unqualified name).
|
||
|
||
Quoting Date (pg. 221): "The schema authID for a given schema identifies
|
||
the owner of that schema (and hence the owner of everything described by
|
||
that schema also)."
|
||
|
||
It is very important that we reach a conclusion on this as it simplifies
|
||
things a lot.
|
||
|
||
Regards,
|
||
Fernando
|
||
|
||
|
||
P.S.: That is why I was telling you that, except for the namespace part,
|
||
we already have the groundwork for Entry-level SQL-Schemas (where the
|
||
schema is always the authorization-id of the creator) -- it is just
|
||
a question of handling the "owner" appropriately.
|
||
|
||
|
||
--
|
||
Fernando Nasser
|
||
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
|
||
2323 Yonge Street, Suite #300
|
||
Toronto, Ontario M4P 2C9
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 2: you can get off all lists at once with the unregister command
|
||
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
|
||
|
||
From pgsql-hackers-owner+M17973=candle.pha.pa.us=pgman@postgresql.org Tue Jan 22 11:26:13 2002
|
||
Return-path: <pgsql-hackers-owner+M17973=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0MGQCU09218
|
||
for <pgman@candle.pha.pa.us>; Tue, 22 Jan 2002 11:26:12 -0500 (EST)
|
||
Received: (qmail 4629 invoked by alias); 22 Jan 2002 16:25:41 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 22 Jan 2002 16:25:41 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0MGGTl95123
|
||
for <pgsql-hackers@postgresql.org>; Tue, 22 Jan 2002 11:16:29 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0MGGBf15342;
|
||
Tue, 22 Jan 2002 11:16:11 -0500 (EST)
|
||
To: Fernando Nasser <fnasser@redhat.com>
|
||
cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <3C4D8A39.FF79CDC4@redhat.com>
|
||
References: <Pine.LNX.4.30.0201211840260.687-100000@peter.localdomain> <12239.1011661590@sss.pgh.pa.us> <3C4D8A39.FF79CDC4@redhat.com>
|
||
Comments: In-reply-to Fernando Nasser <fnasser@redhat.com>
|
||
message dated "Tue, 22 Jan 2002 10:50:17 -0500"
|
||
Date: Tue, 22 Jan 2002 11:16:11 -0500
|
||
Message-ID: <15339.1011716171@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Fernando Nasser <fnasser@redhat.com> writes:
|
||
> Tom Lane wrote:
|
||
>> I don't buy that premise. It's true that SQL92 equates ownership of a
|
||
>> schema with ownership of the objects therein, but AFAICS we have no hope
|
||
>> of being forward-compatible with existing database setups (wherein there
|
||
>> can be multiple tables of different ownership all in a single namespace)
|
||
>> if we don't allow varying ownership within a schema.
|
||
|
||
> Quoting Date (pg. 221): "The schema authID for a given schema identifies
|
||
> the owner of that schema (and hence the owner of everything described by
|
||
> that schema also)."
|
||
|
||
Yes, I know what the spec says. I also think we'll have a revolt on our
|
||
hands if we don't make it possible for existing Postgres applications to
|
||
continue working as they have in the past --- and that means allowing
|
||
tables of different ownerships to be accessible in a single namespace.
|
||
|
||
Although I haven't thought through the details yet, it seems to me that
|
||
a solution exists along these lines:
|
||
|
||
1. The creator of an object owns it. (With some special cases, eg the
|
||
superuser should be able to create a schema owned by someone else.)
|
||
|
||
2. Whether you can create an object in a schema that is owned by someone
|
||
else depends on permissions attached to the schema. By default only
|
||
the owner of a schema can create anything in it.
|
||
|
||
3. SQL92-compatible behavior is achieved when everyone has their own
|
||
schema and they don't grant each other create-in-schema rights.
|
||
Backwards-compatible behavior is achieved when everyone uses a
|
||
shared "public" schema.
|
||
|
||
We'd probably need GUC variable(s) to make it possible to choose which
|
||
behavior is the default. I haven't thought much about exactly what
|
||
knobs should be provided. I do think we will want at least these two
|
||
knobs:
|
||
|
||
1. A "search path" that is an ordered list of schemas to look in
|
||
when trying to resolve an unqualified name.
|
||
|
||
2. A "default schema" variable that identifies the schema to create
|
||
objects in, if a fully qualified name is not given.
|
||
|
||
The default creation location shouldn't be hardwired to equal the
|
||
front of the search path, because the front item of the search path
|
||
is probably always going to be a backend-local temporary schema
|
||
(this is where we'll create temporary tables).
|
||
|
||
The most dumbed-down version of this that would work is to reduce the
|
||
search path to just a fixed list of three locations: temp schema, a
|
||
selectable default schema (which is also the default creation location),
|
||
and a system schema (where pg_class and friends live). But a
|
||
user-settable path wouldn't be any more effort to support, and might
|
||
offer some useful capability.
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 3: if posting/reading through Usenet, please send an appropriate
|
||
subscribe-nomail command to majordomo@postgresql.org so that your
|
||
message can get through to the mailing list cleanly
|
||
|
||
From pgsql-hackers-owner+M17976=candle.pha.pa.us=pgman@postgresql.org Tue Jan 22 12:04:19 2002
|
||
Return-path: <pgsql-hackers-owner+M17976=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0MH4IU12377
|
||
for <pgman@candle.pha.pa.us>; Tue, 22 Jan 2002 12:04:18 -0500 (EST)
|
||
Received: (qmail 20616 invoked by alias); 22 Jan 2002 17:04:13 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 22 Jan 2002 17:04:13 -0000
|
||
Received: from cygnus.com (runyon.sfbay.redhat.com [205.180.230.5] (may be forged))
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0MGiKl15781
|
||
for <pgsql-hackers@postgresql.org>; Tue, 22 Jan 2002 11:44:20 -0500 (EST)
|
||
(envelope-from fnasser@redhat.com)
|
||
Received: from redhat.com (rtl.sfbay.redhat.com [205.180.230.21])
|
||
by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id IAA14751;
|
||
Tue, 22 Jan 2002 08:44:15 -0800 (PST)
|
||
Message-ID: <3C4D96C5.80BBF764@redhat.com>
|
||
Date: Tue, 22 Jan 2002 11:43:49 -0500
|
||
From: Fernando Nasser <fnasser@redhat.com>
|
||
Organization: Red Hat Canada
|
||
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686)
|
||
X-Accept-Language: en
|
||
MIME-Version: 1.0
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
References: <Pine.LNX.4.30.0201211840260.687-100000@peter.localdomain> <12239.1011661590@sss.pgh.pa.us> <3C4D8A39.FF79CDC4@redhat.com> <15339.1011716171@sss.pgh.pa.us>
|
||
Content-Type: text/plain; charset=us-ascii
|
||
Content-Transfer-Encoding: 7bit
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Tom Lane wrote:
|
||
>
|
||
> > Quoting Date (pg. 221): "The schema authID for a given schema identifies
|
||
> > the owner of that schema (and hence the owner of everything described by
|
||
> > that schema also)."
|
||
>
|
||
> Yes, I know what the spec says. I also think we'll have a revolt on our
|
||
> hands if we don't make it possible for existing Postgres applications to
|
||
> continue working as they have in the past --- and that means allowing
|
||
> tables of different ownerships to be accessible in a single namespace.
|
||
>
|
||
|
||
But them it is not SQL-Schemas. Call it something else, "packages"
|
||
for instance. The standard has lots of rules and other considerations
|
||
all around the document that depend on schemas have the meaning they
|
||
assigned to it.
|
||
|
||
If someone wants to really make use of SQL-Schemas, he/she will need to
|
||
reorg the database anyway, which will probably mean dumping the data,
|
||
massaging the DLL and recreating it. I guess most users of SQL-Schemas
|
||
will be people creating new databases.
|
||
|
||
For the current users, (based on your idea below) a default behavior of
|
||
searching the current-AuthID schema, them the "default" schema them
|
||
"any"
|
||
schema will probably make things work.
|
||
|
||
Fernando
|
||
|
||
P.S.: Note that the standard has no GRANTs for SCHEMAs themselves; all
|
||
GRANTS go to the specific objects as before.
|
||
|
||
|
||
> Although I haven't thought through the details yet, it seems to me that
|
||
> a solution exists along these lines:
|
||
>
|
||
> 1. The creator of an object owns it. (With some special cases, eg the
|
||
> superuser should be able to create a schema owned by someone else.)
|
||
>
|
||
> 2. Whether you can create an object in a schema that is owned by someone
|
||
> else depends on permissions attached to the schema. By default only
|
||
> the owner of a schema can create anything in it.
|
||
>
|
||
> 3. SQL92-compatible behavior is achieved when everyone has their own
|
||
> schema and they don't grant each other create-in-schema rights.
|
||
> Backwards-compatible behavior is achieved when everyone uses a
|
||
> shared "public" schema.
|
||
>
|
||
> We'd probably need GUC variable(s) to make it possible to choose which
|
||
> behavior is the default. I haven't thought much about exactly what
|
||
> knobs should be provided. I do think we will want at least these two
|
||
> knobs:
|
||
>
|
||
> 1. A "search path" that is an ordered list of schemas to look in
|
||
> when trying to resolve an unqualified name.
|
||
>
|
||
> 2. A "default schema" variable that identifies the schema to create
|
||
> objects in, if a fully qualified name is not given.
|
||
>
|
||
> The default creation location shouldn't be hardwired to equal the
|
||
> front of the search path, because the front item of the search path
|
||
> is probably always going to be a backend-local temporary schema
|
||
> (this is where we'll create temporary tables).
|
||
>
|
||
> The most dumbed-down version of this that would work is to reduce the
|
||
> search path to just a fixed list of three locations: temp schema, a
|
||
> selectable default schema (which is also the default creation location),
|
||
> and a system schema (where pg_class and friends live). But a
|
||
> user-settable path wouldn't be any more effort to support, and might
|
||
> offer some useful capability.
|
||
>
|
||
> regards, tom lane
|
||
>
|
||
> ---------------------------(end of broadcast)---------------------------
|
||
> TIP 3: if posting/reading through Usenet, please send an appropriate
|
||
> subscribe-nomail command to majordomo@postgresql.org so that your
|
||
> message can get through to the mailing list cleanly
|
||
|
||
--
|
||
Fernando Nasser
|
||
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
|
||
2323 Yonge Street, Suite #300
|
||
Toronto, Ontario M4P 2C9
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 6: Have you searched our list archives?
|
||
|
||
http://archives.postgresql.org
|
||
|
||
From pgsql-hackers-owner+M17976=candle.pha.pa.us=pgman@postgresql.org Tue Jan 22 12:04:19 2002
|
||
Return-path: <pgsql-hackers-owner+M17976=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0MH4IU12378
|
||
for <pgman@candle.pha.pa.us>; Tue, 22 Jan 2002 12:04:18 -0500 (EST)
|
||
Received: (qmail 20627 invoked by alias); 22 Jan 2002 17:04:13 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 22 Jan 2002 17:04:13 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0MGpjl18339
|
||
for <pgsql-hackers@postgresql.org>; Tue, 22 Jan 2002 11:51:45 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0MGpUf15641;
|
||
Tue, 22 Jan 2002 11:51:30 -0500 (EST)
|
||
To: Fernando Nasser <fnasser@redhat.com>
|
||
cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <3C4D96C5.80BBF764@redhat.com>
|
||
References: <Pine.LNX.4.30.0201211840260.687-100000@peter.localdomain> <12239.1011661590@sss.pgh.pa.us> <3C4D8A39.FF79CDC4@redhat.com> <15339.1011716171@sss.pgh.pa.us> <3C4D96C5.80BBF764@redhat.com>
|
||
Comments: In-reply-to Fernando Nasser <fnasser@redhat.com>
|
||
message dated "Tue, 22 Jan 2002 11:43:49 -0500"
|
||
Date: Tue, 22 Jan 2002 11:51:30 -0500
|
||
Message-ID: <15638.1011718290@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Fernando Nasser <fnasser@redhat.com> writes:
|
||
> But them it is not SQL-Schemas. Call it something else, "packages"
|
||
> for instance. The standard has lots of rules and other considerations
|
||
> all around the document that depend on schemas have the meaning they
|
||
> assigned to it.
|
||
|
||
Where? And are there any cases where it really matters?
|
||
|
||
> If someone wants to really make use of SQL-Schemas, he/she will need to
|
||
> reorg the database anyway, which will probably mean dumping the data,
|
||
> massaging the DLL and recreating it. I guess most users of SQL-Schemas
|
||
> will be people creating new databases.
|
||
|
||
No doubt. That still leaves us with the problem of providing
|
||
backward-compatible behavior in an engine that is going to be designed
|
||
to support schemas. I'm not sure what you think the implementation of
|
||
schemas is going to look like --- but I think it's not going to be
|
||
something that can be turned off or ignored. Every table is going to
|
||
belong to some schema, and the old behavior has to be available within
|
||
that framework.
|
||
|
||
We are not working in a vacuum here, and that means that "implement
|
||
the specification and nothing but" is not a workable design approach.
|
||
We are going to end up with something that does the things SQL92 asks
|
||
for, but does other things too.
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 4: Don't 'kill -9' the postmaster
|
||
|
||
From pgsql-hackers-owner+M17980=candle.pha.pa.us=pgman@postgresql.org Tue Jan 22 15:34:09 2002
|
||
Return-path: <pgsql-hackers-owner+M17980=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0MKY7U05934
|
||
for <pgman@candle.pha.pa.us>; Tue, 22 Jan 2002 15:34:07 -0500 (EST)
|
||
Received: (qmail 77926 invoked by alias); 22 Jan 2002 20:33:26 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 22 Jan 2002 20:33:26 -0000
|
||
Received: from cygnus.com (runyon.sfbay.redhat.com [205.180.230.5] (may be forged))
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0MKUrl76871
|
||
for <pgsql-hackers@postgresql.org>; Tue, 22 Jan 2002 15:30:54 -0500 (EST)
|
||
(envelope-from fnasser@redhat.com)
|
||
Received: from redhat.com (rtl.sfbay.redhat.com [205.180.230.21])
|
||
by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id MAA09466;
|
||
Tue, 22 Jan 2002 12:30:46 -0800 (PST)
|
||
Message-ID: <3C4DCBDB.689D7201@redhat.com>
|
||
Date: Tue, 22 Jan 2002 15:30:20 -0500
|
||
From: Fernando Nasser <fnasser@redhat.com>
|
||
Organization: Red Hat Canada
|
||
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686)
|
||
X-Accept-Language: en
|
||
MIME-Version: 1.0
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
References: <Pine.LNX.4.30.0201211840260.687-100000@peter.localdomain> <12239.1011661590@sss.pgh.pa.us> <3C4D8A39.FF79CDC4@redhat.com> <15339.1011716171@sss.pgh.pa.us> <3C4D96C5.80BBF764@redhat.com> <15638.1011718290@sss.pgh.pa.us>
|
||
Content-Type: text/plain; charset=us-ascii
|
||
Content-Transfer-Encoding: 7bit
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
OK, so the proposal is that we dissociate the ownership from the
|
||
namespace when we implement our version of SQL-Schemas, right?
|
||
This way an object will have both an owner and a schema (while in
|
||
the standard they are the same thing).
|
||
|
||
The important is not much to accommodate someone who is creating
|
||
schemas (a new thing, so objects can be created the "right" way)
|
||
but rather to accommodate current code that does not use schemas
|
||
and have several owners for the objects (which would all fall
|
||
into a "default" schema). Can you agree with that?
|
||
|
||
I was looking to see if we choose the proper defaults and search paths
|
||
and the "default" schema we could make it look for SQL-compliant code
|
||
as if it was a vanilla SQL-Schemas implementation.
|
||
|
||
To support the current database schema definitions (without SQL-Schemas
|
||
and with different owners), things would be created with the current
|
||
user authorization id and will have its name defined in the "default"
|
||
SQL-Schema
|
||
namespace. Also, when referring to an object if the name is not
|
||
qualified
|
||
with the schema name, the search would go through the schema with the
|
||
current authorization id (as required by the std) and proceed to check
|
||
the "default" schema.
|
||
|
||
The only problem in the scenario above is that the standard says that
|
||
when creating objects and not specifying the schema the schema name
|
||
should be assumed to be the current user authorization id (or whatever
|
||
authorization id the code is running as). In our case it would go to
|
||
the default schema. If someone wants the SQL std behavior then, he/she
|
||
must create things inside a CREATE SCHEMA statement or explicitly
|
||
qualify
|
||
with the schema name the objects being created. Can we live with that?
|
||
Will we pass the conformance tests? (I saw tests that test the schema
|
||
name
|
||
that is assumed when referencing but I do not recall seeing one that
|
||
tests
|
||
what is assumed on creation -- things I saw were all created inside
|
||
CREATE SCHEMA statements. Note, also, that passing the NIST tests
|
||
doesn't
|
||
make us compliant if we know that we are doing something different than
|
||
what is specified -- it just means that we got away with it :-)
|
||
|
||
|
||
--
|
||
Fernando Nasser
|
||
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
|
||
2323 Yonge Street, Suite #300
|
||
Toronto, Ontario M4P 2C9
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 2: you can get off all lists at once with the unregister command
|
||
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
|
||
|
||
From pgsql-hackers-owner+M17982=candle.pha.pa.us=pgman@postgresql.org Tue Jan 22 15:46:46 2002
|
||
Return-path: <pgsql-hackers-owner+M17982=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0MKkhU07389
|
||
for <pgman@candle.pha.pa.us>; Tue, 22 Jan 2002 15:46:44 -0500 (EST)
|
||
Received: (qmail 82732 invoked by alias); 22 Jan 2002 20:43:40 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 22 Jan 2002 20:43:40 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0MKg8l81714
|
||
for <pgsql-hackers@postgresql.org>; Tue, 22 Jan 2002 15:42:08 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0MKfnf28202;
|
||
Tue, 22 Jan 2002 15:41:49 -0500 (EST)
|
||
To: Fernando Nasser <fnasser@redhat.com>
|
||
cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <3C4DCBDB.689D7201@redhat.com>
|
||
References: <Pine.LNX.4.30.0201211840260.687-100000@peter.localdomain> <12239.1011661590@sss.pgh.pa.us> <3C4D8A39.FF79CDC4@redhat.com> <15339.1011716171@sss.pgh.pa.us> <3C4D96C5.80BBF764@redhat.com> <15638.1011718290@sss.pgh.pa.us> <3C4DCBDB.689D7201@redhat.com>
|
||
Comments: In-reply-to Fernando Nasser <fnasser@redhat.com>
|
||
message dated "Tue, 22 Jan 2002 15:30:20 -0500"
|
||
Date: Tue, 22 Jan 2002 15:41:49 -0500
|
||
Message-ID: <28199.1011732109@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Fernando Nasser <fnasser@redhat.com> writes:
|
||
> The only problem in the scenario above is that the standard says that
|
||
> when creating objects and not specifying the schema the schema name
|
||
> should be assumed to be the current user authorization id (or whatever
|
||
> authorization id the code is running as). In our case it would go to
|
||
> the default schema. If someone wants the SQL std behavior then, he/she
|
||
> must create things inside a CREATE SCHEMA statement or explicitly
|
||
> qualify
|
||
> with the schema name the objects being created. Can we live with
|
||
> that?
|
||
|
||
Huh? You seem to be assuming that we need to support both the
|
||
historical Postgres behavior and the SQL-standard behavior with exactly
|
||
the same configuration switches. That's not how I'm seeing it at all.
|
||
The way I'm envisioning it, you could get either the historical
|
||
behavior, or the standard's behavior, depending on how you set up the
|
||
configuration variables. I don't see any particular reason to limit the
|
||
system to just those two cases, either, if the underlying implementation
|
||
has enough flexibility to support custom namespace configurations.
|
||
|
||
I believe that we could get the historical behavior with something like
|
||
|
||
schema search path = ("public" schema, system schema);
|
||
|
||
default creation schema = "public" schema
|
||
|
||
and the standard's behavior with something like
|
||
|
||
schema search path = (user's own schema, system schema);
|
||
|
||
default creation schema = user's own schema
|
||
|
||
(ignoring the issue of a schema for temp tables for the moment).
|
||
|
||
If you prefer to think of these things as "namespaces" rather than
|
||
"schemas", that's fine with me ... what we're talking about here
|
||
is an implementation that can support SQL-style schemas, but isn't
|
||
narrowly able to do only that.
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
|
||
|
||
From pgsql-hackers-owner+M17985=candle.pha.pa.us=pgman@postgresql.org Tue Jan 22 16:15:56 2002
|
||
Return-path: <pgsql-hackers-owner+M17985=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0MLFrU10671
|
||
for <pgman@candle.pha.pa.us>; Tue, 22 Jan 2002 16:15:53 -0500 (EST)
|
||
Received: (qmail 94223 invoked by alias); 22 Jan 2002 21:14:17 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 22 Jan 2002 21:14:17 -0000
|
||
Received: from cygnus.com (runyon.sfbay.redhat.com [205.180.230.5] (may be forged))
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0ML2fl90295
|
||
for <pgsql-hackers@postgresql.org>; Tue, 22 Jan 2002 16:02:41 -0500 (EST)
|
||
(envelope-from fnasser@redhat.com)
|
||
Received: from redhat.com (rtl.sfbay.redhat.com [205.180.230.21])
|
||
by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id NAA12269;
|
||
Tue, 22 Jan 2002 13:02:34 -0800 (PST)
|
||
Message-ID: <3C4DD34F.CC4D8B6@redhat.com>
|
||
Date: Tue, 22 Jan 2002 16:02:07 -0500
|
||
From: Fernando Nasser <fnasser@redhat.com>
|
||
Organization: Red Hat Canada
|
||
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686)
|
||
X-Accept-Language: en
|
||
MIME-Version: 1.0
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
References: <Pine.LNX.4.30.0201211840260.687-100000@peter.localdomain> <12239.1011661590@sss.pgh.pa.us> <3C4D8A39.FF79CDC4@redhat.com> <15339.1011716171@sss.pgh.pa.us> <3C4D96C5.80BBF764@redhat.com> <15638.1011718290@sss.pgh.pa.us> <3C4DCBDB.689D7201@redhat.com> <28199.1011732109@sss.pgh.pa.us>
|
||
Content-Type: text/plain; charset=us-ascii
|
||
Content-Transfer-Encoding: 7bit
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Tom Lane wrote:
|
||
>
|
||
> Huh? You seem to be assuming that we need to support both the
|
||
> historical Postgres behavior and the SQL-standard behavior with exactly
|
||
> the same configuration switches. That's not how I'm seeing it at all.
|
||
> The way I'm envisioning it, you could get either the historical
|
||
> behavior, or the standard's behavior, depending on how you set up the
|
||
> configuration variables.
|
||
|
||
Then we can live just with the schema being the ownership.
|
||
|
||
Switches set to standard:
|
||
|
||
schema search path = ("user's own schema", postgres)
|
||
|
||
[ default creation schema = user's own schema ] same as below,
|
||
we don't need this
|
||
switch
|
||
|
||
Switches set to historical:
|
||
|
||
schema search path = (user's own schema, "any" schema, postgres)
|
||
|
||
[ default creation schema = user's own schema ]
|
||
|
||
The searching in "any" schema (i.e., any owner) will let will find
|
||
things that where defined the way they are today, i.e., possibly
|
||
by several different users.
|
||
|
||
|
||
P.S.: You can even add the "default" schema in the standard case and
|
||
I believe you are still compliant and can handle things easier:
|
||
schema search path = ("user's own schema", postgres)
|
||
|
||
|
||
Maybe you could give an example of a case where the schema meaning
|
||
ownership breaks things. Or what kind of additional things you have
|
||
in mind that would require orthogonal schema and ownership spaces.
|
||
|
||
|
||
Regards,
|
||
Fernando
|
||
|
||
|
||
|
||
|
||
--
|
||
Fernando Nasser
|
||
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
|
||
2323 Yonge Street, Suite #300
|
||
Toronto, Ontario M4P 2C9
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 3: if posting/reading through Usenet, please send an appropriate
|
||
subscribe-nomail command to majordomo@postgresql.org so that your
|
||
message can get through to the mailing list cleanly
|
||
|
||
From pgsql-hackers-owner+M17986=candle.pha.pa.us=pgman@postgresql.org Tue Jan 22 16:23:41 2002
|
||
Return-path: <pgsql-hackers-owner+M17986=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0MLNbU11596
|
||
for <pgman@candle.pha.pa.us>; Tue, 22 Jan 2002 16:23:38 -0500 (EST)
|
||
Received: (qmail 703 invoked by alias); 22 Jan 2002 21:23:31 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 22 Jan 2002 21:23:31 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0MLEYl94662
|
||
for <pgsql-hackers@postgresql.org>; Tue, 22 Jan 2002 16:14:34 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0MLEGf28560;
|
||
Tue, 22 Jan 2002 16:14:17 -0500 (EST)
|
||
To: Fernando Nasser <fnasser@redhat.com>
|
||
cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <3C4DD34F.CC4D8B6@redhat.com>
|
||
References: <Pine.LNX.4.30.0201211840260.687-100000@peter.localdomain> <12239.1011661590@sss.pgh.pa.us> <3C4D8A39.FF79CDC4@redhat.com> <15339.1011716171@sss.pgh.pa.us> <3C4D96C5.80BBF764@redhat.com> <15638.1011718290@sss.pgh.pa.us> <3C4DCBDB.689D7201@redhat.com> <28199.1011732109@sss.pgh.pa.us> <3C4DD34F.CC4D8B6@redhat.com>
|
||
Comments: In-reply-to Fernando Nasser <fnasser@redhat.com>
|
||
message dated "Tue, 22 Jan 2002 16:02:07 -0500"
|
||
Date: Tue, 22 Jan 2002 16:14:16 -0500
|
||
Message-ID: <28557.1011734056@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Fernando Nasser <fnasser@redhat.com> writes:
|
||
> Switches set to historical:
|
||
|
||
> schema search path = (user's own schema, "any" schema, postgres)
|
||
|
||
> [ default creation schema = user's own schema ]
|
||
|
||
> The searching in "any" schema (i.e., any owner) will let will find
|
||
> things that where defined the way they are today, i.e., possibly
|
||
> by several different users.
|
||
|
||
No, it won't, because nothing will ever get put into that schema.
|
||
(At least not by existing pg_dump scripts, which are the things that
|
||
really need to see the historical behavior.) The
|
||
default-creation-schema variable has got to point at any/public/
|
||
whatever-we-call it, or you do not have the historical behavior.
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 3: if posting/reading through Usenet, please send an appropriate
|
||
subscribe-nomail command to majordomo@postgresql.org so that your
|
||
message can get through to the mailing list cleanly
|
||
|
||
From pgsql-hackers-owner+M17988=candle.pha.pa.us=pgman@postgresql.org Tue Jan 22 16:44:43 2002
|
||
Return-path: <pgsql-hackers-owner+M17988=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0MLifU13572
|
||
for <pgman@candle.pha.pa.us>; Tue, 22 Jan 2002 16:44:41 -0500 (EST)
|
||
Received: (qmail 8653 invoked by alias); 22 Jan 2002 21:43:27 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 22 Jan 2002 21:43:27 -0000
|
||
Received: from cygnus.com (runyon.sfbay.redhat.com [205.180.230.5] (may be forged))
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0MLR6l02610
|
||
for <pgsql-hackers@postgresql.org>; Tue, 22 Jan 2002 16:27:06 -0500 (EST)
|
||
(envelope-from fnasser@redhat.com)
|
||
Received: from redhat.com (rtl.sfbay.redhat.com [205.180.230.21])
|
||
by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id NAA14337;
|
||
Tue, 22 Jan 2002 13:27:00 -0800 (PST)
|
||
Message-ID: <3C4DD909.F26FD0D1@redhat.com>
|
||
Date: Tue, 22 Jan 2002 16:26:33 -0500
|
||
From: Fernando Nasser <fnasser@redhat.com>
|
||
Organization: Red Hat Canada
|
||
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686)
|
||
X-Accept-Language: en
|
||
MIME-Version: 1.0
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
References: <Pine.LNX.4.30.0201211840260.687-100000@peter.localdomain> <12239.1011661590@sss.pgh.pa.us> <3C4D8A39.FF79CDC4@redhat.com> <15339.1011716171@sss.pgh.pa.us> <3C4D96C5.80BBF764@redhat.com> <15638.1011718290@sss.pgh.pa.us> <3C4DCBDB.689D7201@redhat.com> <28199.1011732109@sss.pgh.pa.us> <3C4DD34F.CC4D8B6@redhat.com> <28557.1011734056@sss.pgh.pa.us>
|
||
Content-Type: text/plain; charset=us-ascii
|
||
Content-Transfer-Encoding: 7bit
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Tom Lane wrote:
|
||
>
|
||
> Fernando Nasser <fnasser@redhat.com> writes:
|
||
> > Switches set to historical:
|
||
>
|
||
> > schema search path = (user's own schema, "any" schema, postgres)
|
||
>
|
||
> > [ default creation schema = user's own schema ]
|
||
>
|
||
> > The searching in "any" schema (i.e., any owner) will let will find
|
||
> > things that where defined the way they are today, i.e., possibly
|
||
> > by several different users.
|
||
>
|
||
> No, it won't, because nothing will ever get put into that schema.
|
||
> (At least not by existing pg_dump scripts, which are the things that
|
||
> really need to see the historical behavior.) The
|
||
> default-creation-schema variable has got to point at any/public/
|
||
> whatever-we-call it, or you do not have the historical behavior.
|
||
>
|
||
|
||
You did not understand what I meant by "any". It is not a schema
|
||
called "any". It is _any_ schema.
|
||
|
||
Example:
|
||
|
||
A creates a table (do not specify the schema) so it gets into
|
||
the schema named A (as per standard).
|
||
|
||
B refers to the table without qualifying it...
|
||
|
||
In the standard case: look into schema B (=> not found), not in
|
||
postgres either.
|
||
ERROR: Inv. relation As the standard requires.
|
||
|
||
In the historical mode: look into schema B (=> not found), look into
|
||
ANY
|
||
schema (finds it in A). Works as it is today.
|
||
|
||
|
||
Note that I only suggest looking in B first (in the historical case)
|
||
because
|
||
this will allow for the coexistence of the current mode with a
|
||
quasi-compliant
|
||
use of SQL-Schemas. You only need to change the switch if you want
|
||
strict
|
||
compliance.
|
||
|
||
|
||
|
||
--
|
||
Fernando Nasser
|
||
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
|
||
2323 Yonge Street, Suite #300
|
||
Toronto, Ontario M4P 2C9
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 4: Don't 'kill -9' the postmaster
|
||
|
||
From pgsql-hackers-owner+M17987=candle.pha.pa.us=pgman@postgresql.org Tue Jan 22 16:45:30 2002
|
||
Return-path: <pgsql-hackers-owner+M17987=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0MLjSU13642
|
||
for <pgman@candle.pha.pa.us>; Tue, 22 Jan 2002 16:45:29 -0500 (EST)
|
||
Received: (qmail 8533 invoked by alias); 22 Jan 2002 21:43:23 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 22 Jan 2002 21:43:23 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0MLZ5l06911
|
||
for <pgsql-hackers@postgresql.org>; Tue, 22 Jan 2002 16:35:05 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0MLYlf28790;
|
||
Tue, 22 Jan 2002 16:34:47 -0500 (EST)
|
||
To: Fernando Nasser <fnasser@redhat.com>
|
||
cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <3C4DD909.F26FD0D1@redhat.com>
|
||
References: <Pine.LNX.4.30.0201211840260.687-100000@peter.localdomain> <12239.1011661590@sss.pgh.pa.us> <3C4D8A39.FF79CDC4@redhat.com> <15339.1011716171@sss.pgh.pa.us> <3C4D96C5.80BBF764@redhat.com> <15638.1011718290@sss.pgh.pa.us> <3C4DCBDB.689D7201@redhat.com> <28199.1011732109@sss.pgh.pa.us> <3C4DD34F.CC4D8B6@redhat.com> <28557.1011734056@sss.pgh.pa.us> <3C4DD909.F26FD0D1@redhat.com>
|
||
Comments: In-reply-to Fernando Nasser <fnasser@redhat.com>
|
||
message dated "Tue, 22 Jan 2002 16:26:33 -0500"
|
||
Date: Tue, 22 Jan 2002 16:34:47 -0500
|
||
Message-ID: <28787.1011735287@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Fernando Nasser <fnasser@redhat.com> writes:
|
||
> In the historical mode: look into schema B (=> not found), look into
|
||
> ANY schema (finds it in A). Works as it is today.
|
||
|
||
No, it doesn't work the same as today, because in that implementation
|
||
both A and B can create the same tablename without complaint. It then
|
||
becomes very unclear which instance other people will get (unless your
|
||
"any" placeholder somehow implies a search order).
|
||
|
||
The idea of being able to put an "any" placeholder into the search list
|
||
is an interesting one, though. If we can resolve the ambiguity problem
|
||
it might be a useful feature.
|
||
|
||
I am a little troubled by the idea of placing "any" before the system
|
||
schema (what if JRandomLuser creates a table named "pg_class"?) but it
|
||
might be workable at the tail end of the path.
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 4: Don't 'kill -9' the postmaster
|
||
|
||
From pgsql-hackers-owner+M17991=candle.pha.pa.us=pgman@postgresql.org Tue Jan 22 17:13:49 2002
|
||
Return-path: <pgsql-hackers-owner+M17991=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0MMDmU19678
|
||
for <pgman@candle.pha.pa.us>; Tue, 22 Jan 2002 17:13:49 -0500 (EST)
|
||
Received: (qmail 19170 invoked by alias); 22 Jan 2002 22:13:14 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 22 Jan 2002 22:13:14 -0000
|
||
Received: from cygnus.com (runyon.sfbay.redhat.com [205.180.230.5] (may be forged))
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0MM3ql17554
|
||
for <pgsql-hackers@postgresql.org>; Tue, 22 Jan 2002 17:03:53 -0500 (EST)
|
||
(envelope-from fnasser@redhat.com)
|
||
Received: from redhat.com (rtl.sfbay.redhat.com [205.180.230.21])
|
||
by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id OAA18084;
|
||
Tue, 22 Jan 2002 14:03:46 -0800 (PST)
|
||
Message-ID: <3C4DE1A7.98860E96@redhat.com>
|
||
Date: Tue, 22 Jan 2002 17:03:19 -0500
|
||
From: Fernando Nasser <fnasser@redhat.com>
|
||
Organization: Red Hat Canada
|
||
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686)
|
||
X-Accept-Language: en
|
||
MIME-Version: 1.0
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
References: <Pine.LNX.4.30.0201211840260.687-100000@peter.localdomain> <12239.1011661590@sss.pgh.pa.us> <3C4D8A39.FF79CDC4@redhat.com> <15339.1011716171@sss.pgh.pa.us> <3C4D96C5.80BBF764@redhat.com> <15638.1011718290@sss.pgh.pa.us> <3C4DCBDB.689D7201@redhat.com> <28199.1011732109@sss.pgh.pa.us> <3C4DD34F.CC4D8B6@redhat.com> <28557.1011734056@sss.pgh.pa.us> <3C4DD909.F26FD0D1@redhat.com> <28787.1011735287@sss.pgh.pa.us>
|
||
Content-Type: text/plain; charset=us-ascii
|
||
Content-Transfer-Encoding: 7bit
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Tom Lane wrote:
|
||
>
|
||
> Fernando Nasser <fnasser@redhat.com> writes:
|
||
> > In the historical mode: look into schema B (=> not found), look into
|
||
> > ANY schema (finds it in A). Works as it is today.
|
||
>
|
||
> No, it doesn't work the same as today, because in that implementation
|
||
> both A and B can create the same tablename without complaint.
|
||
|
||
I agree that we won't be able to catch this as an error unless we turn
|
||
another switch that requires unique names (there goes one of the
|
||
advantages
|
||
of having schemas, but there is always the option of leaving it on).
|
||
|
||
In this case it would be more close to the current behavior but what is
|
||
left of the SQL-Schemas will be more of a syntactic sugar (although it
|
||
can
|
||
be still used by the DBA to better organize the grant of privileges).
|
||
|
||
Anyway, it would be a DBA option to live with not detecting duplicate
|
||
names. And, I hope all our tools, graphical or not, will make it clear
|
||
what
|
||
is the schema things are defined into, so it would not be difficult to
|
||
figure out what is going wrong if something goes wrong (and we can also
|
||
print the relation oid on messages).
|
||
|
||
> It then
|
||
> becomes very unclear which instance other people will get (unless your
|
||
> "any" placeholder somehow implies a search order).
|
||
>
|
||
|
||
If someone is just using the current mode, there shouldn't be (all names
|
||
are
|
||
database-unique).
|
||
|
||
The only case where this situation can happen is if someone is trying
|
||
to use schemas and the historical non-schema organization in the same
|
||
database, right? Can we make the search order per database?)
|
||
|
||
One possibility is to state that this is not recommended (one should
|
||
organize things as schemas or not at all in a database) and say that
|
||
the search order, besides the current AuthId, is unspecified (random).
|
||
|
||
Another possibility is to allow only one object with that name in the
|
||
"any" space. If someone means an object that was defined on a schema,
|
||
he/she can qualify the name with the schema (good practice). The only
|
||
case where this is not possible is the legacy case, where there is
|
||
exactly one object with that name anyway.
|
||
|
||
I prefer this second solution.
|
||
|
||
> The idea of being able to put an "any" placeholder into the search list
|
||
> is an interesting one, though. If we can resolve the ambiguity problem
|
||
> it might be a useful feature.
|
||
>
|
||
|
||
See above.
|
||
|
||
> I am a little troubled by the idea of placing "any" before the system
|
||
> schema (what if JRandomLuser creates a table named "pg_class"?) but it
|
||
> might be workable at the tail end of the path.
|
||
>
|
||
|
||
Yes, I thought of that as I was typing, but it was not the important
|
||
point at that time. You're right, should go at the end.
|
||
|
||
--
|
||
Fernando Nasser
|
||
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
|
||
2323 Yonge Street, Suite #300
|
||
Toronto, Ontario M4P 2C9
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 5: Have you checked our extensive FAQ?
|
||
|
||
http://www.postgresql.org/users-lounge/docs/faq.html
|
||
|
||
From pgsql-hackers-owner+M17993=candle.pha.pa.us=pgman@postgresql.org Tue Jan 22 18:44:53 2002
|
||
Return-path: <pgsql-hackers-owner+M17993=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0MNiqU29215
|
||
for <pgman@candle.pha.pa.us>; Tue, 22 Jan 2002 18:44:53 -0500 (EST)
|
||
Received: (qmail 36986 invoked by alias); 22 Jan 2002 23:43:31 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 22 Jan 2002 23:43:31 -0000
|
||
Received: from student.gvsu.edu ([148.61.7.124])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0MNGYl30543
|
||
for <pgsql-hackers@postgreSQL.org>; Tue, 22 Jan 2002 18:16:34 -0500 (EST)
|
||
(envelope-from peter_e@gmx.net)
|
||
Received: from [148.61.250.147] [148.61.250.147] by student.gvsu.edu
|
||
with Novonyx SMTP Server $Revision: 1.3 $; Tue, 22 Jan 2002 18:16:37 -0500 (EDT)
|
||
Date: Tue, 22 Jan 2002 18:18:38 -0500 (EST)
|
||
From: Peter Eisentraut <peter_e@gmx.net>
|
||
X-Sender: <peter@peter.localdomain>
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <12239.1011661590@sss.pgh.pa.us>
|
||
Message-ID: <Pine.LNX.4.30.0201221816130.686-100000@peter.localdomain>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Tom Lane writes:
|
||
|
||
> I don't buy that premise. It's true that SQL92 equates ownership of a
|
||
> schema with ownership of the objects therein, but AFAICS we have no hope
|
||
> of being forward-compatible with existing database setups (wherein there
|
||
> can be multiple tables of different ownership all in a single namespace)
|
||
> if we don't allow varying ownership within a schema.
|
||
|
||
We could have a Boolean knob that says "if you don't find the object in
|
||
the default schema, search all other schemas". That should provide all
|
||
the backward compatibility we need. Moreover, I figure if we do it that
|
||
way, the whole schema implementation reduces itself mostly to parser work,
|
||
no complicated system catalog changes, no complex overhaul of the
|
||
privilege system -- at least initially.
|
||
|
||
--
|
||
Peter Eisentraut peter_e@gmx.net
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
|
||
|
||
From pgsql-hackers-owner+M17992=candle.pha.pa.us=pgman@postgresql.org Tue Jan 22 18:34:48 2002
|
||
Return-path: <pgsql-hackers-owner+M17992=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0MNYmU28419
|
||
for <pgman@candle.pha.pa.us>; Tue, 22 Jan 2002 18:34:48 -0500 (EST)
|
||
Received: (qmail 32848 invoked by alias); 22 Jan 2002 23:34:10 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 22 Jan 2002 23:34:10 -0000
|
||
Received: from student.gvsu.edu ([148.61.7.124])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0MNPUl31485
|
||
for <pgsql-hackers@postgresql.org>; Tue, 22 Jan 2002 18:25:30 -0500 (EST)
|
||
(envelope-from peter_e@gmx.net)
|
||
Received: from [148.61.250.147] [148.61.250.147] by student.gvsu.edu
|
||
with Novonyx SMTP Server $Revision: 1.3 $; Tue, 22 Jan 2002 18:25:33 -0500 (EDT)
|
||
Date: Tue, 22 Jan 2002 18:27:35 -0500 (EST)
|
||
From: Peter Eisentraut <peter_e@gmx.net>
|
||
X-Sender: <peter@peter.localdomain>
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Fernando Nasser <fnasser@redhat.com>, <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <28787.1011735287@sss.pgh.pa.us>
|
||
Message-ID: <Pine.LNX.4.30.0201221824360.686-100000@peter.localdomain>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Tom Lane writes:
|
||
|
||
> No, it doesn't work the same as today, because in that implementation
|
||
> both A and B can create the same tablename without complaint. It then
|
||
> becomes very unclear which instance other people will get (unless your
|
||
> "any" placeholder somehow implies a search order).
|
||
|
||
The "search any schema" switch is only intended for use with legacy
|
||
databases, where duplicate names don't occur anyway. If someone uses it
|
||
with a new schema-using database design, then he kind of ought to know
|
||
that the switch probably doesn't make a whole lot of sense. However, to
|
||
get reproduceable behaviour anyway we can just define a search order, such
|
||
as by schema name.
|
||
|
||
--
|
||
Peter Eisentraut peter_e@gmx.net
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
|
||
|
||
From pgsql-hackers-owner+M17994=candle.pha.pa.us=pgman@postgresql.org Tue Jan 22 18:45:53 2002
|
||
Return-path: <pgsql-hackers-owner+M17994=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0MNjqU29324
|
||
for <pgman@candle.pha.pa.us>; Tue, 22 Jan 2002 18:45:52 -0500 (EST)
|
||
Received: (qmail 37021 invoked by alias); 22 Jan 2002 23:43:34 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 22 Jan 2002 23:43:34 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0MNVOl31958
|
||
for <pgsql-hackers@postgreSQL.org>; Tue, 22 Jan 2002 18:31:24 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0MNV8f29291;
|
||
Tue, 22 Jan 2002 18:31:08 -0500 (EST)
|
||
To: Peter Eisentraut <peter_e@gmx.net>
|
||
cc: pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <Pine.LNX.4.30.0201221816130.686-100000@peter.localdomain>
|
||
References: <Pine.LNX.4.30.0201221816130.686-100000@peter.localdomain>
|
||
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
|
||
message dated "Tue, 22 Jan 2002 18:18:38 -0500"
|
||
Date: Tue, 22 Jan 2002 18:31:08 -0500
|
||
Message-ID: <29288.1011742268@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Peter Eisentraut <peter_e@gmx.net> writes:
|
||
> Moreover, I figure if we do it that
|
||
> way, the whole schema implementation reduces itself mostly to parser work,
|
||
> no complicated system catalog changes, no complex overhaul of the
|
||
> privilege system -- at least initially.
|
||
|
||
Why are you guys so eager to save me work? I'm not in the least
|
||
interested in implementing a "schema" feature that can only handle
|
||
the entry-level user == schema case. Therefore, just relabeling the
|
||
owner column as schema isn't an interesting option.
|
||
|
||
I really don't see what's wrong with building a namespace mechanism
|
||
that is orthogonal to ownership and then using that to implement what
|
||
SQL92 wants. I think this will be cleaner, simpler, and more flexible
|
||
than trying to equate ownership with namespace.
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 6: Have you searched our list archives?
|
||
|
||
http://archives.postgresql.org
|
||
|
||
From pgsql-hackers-owner+M17997=candle.pha.pa.us=pgman@postgresql.org Tue Jan 22 19:13:42 2002
|
||
Return-path: <pgsql-hackers-owner+M17997=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0N0DgU01512
|
||
for <pgman@candle.pha.pa.us>; Tue, 22 Jan 2002 19:13:42 -0500 (EST)
|
||
Received: (qmail 46269 invoked by alias); 23 Jan 2002 00:13:11 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 00:13:11 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0N02bl42634
|
||
for <pgsql-hackers@postgresql.org>; Tue, 22 Jan 2002 19:02:37 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0N02Kf29439;
|
||
Tue, 22 Jan 2002 19:02:21 -0500 (EST)
|
||
To: Peter Eisentraut <peter_e@gmx.net>
|
||
cc: Fernando Nasser <fnasser@redhat.com>, pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <Pine.LNX.4.30.0201221824360.686-100000@peter.localdomain>
|
||
References: <Pine.LNX.4.30.0201221824360.686-100000@peter.localdomain>
|
||
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
|
||
message dated "Tue, 22 Jan 2002 18:27:35 -0500"
|
||
Date: Tue, 22 Jan 2002 19:02:20 -0500
|
||
Message-ID: <29436.1011744140@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Peter Eisentraut <peter_e@gmx.net> writes:
|
||
> Tom Lane writes:
|
||
>> No, it doesn't work the same as today, because in that implementation
|
||
>> both A and B can create the same tablename without complaint. It then
|
||
>> becomes very unclear which instance other people will get (unless your
|
||
>> "any" placeholder somehow implies a search order).
|
||
|
||
> The "search any schema" switch is only intended for use with legacy
|
||
> databases, where duplicate names don't occur anyway.
|
||
|
||
That's a mighty narrow view of the world. Do you think that people had
|
||
better convert to SQL schemas before they ever again create a table?
|
||
The fact is that ordinary non-schema-aware usage will certainly lead to
|
||
the above scenario.
|
||
|
||
> that the switch probably doesn't make a whole lot of sense. However, to
|
||
> get reproduceable behaviour anyway we can just define a search order, such
|
||
> as by schema name.
|
||
|
||
Or say that you get an "ambiguous reference" error if there is more than
|
||
one possible candidate in the "any" namespace. (Although that opens the
|
||
door for innocent creation of a table foo by one user to break other
|
||
people's formerly-working queries that reference some other foo.)
|
||
Bottom line for me is that this is an untried concept. I think the
|
||
concept of an "any" searchlist entry is risky enough that I don't much
|
||
want to hang the entire usability of the implementation on the
|
||
assumption that we won't find any fatal problems with "any".
|
||
|
||
|
||
However, the argument over whether SQL92's concept of ownership should
|
||
be taken as gospel is not really the argument I wanted to have in this
|
||
thread. Is it possible to go back to the original point concerning
|
||
whether there should be different namespace boundaries for different
|
||
types of objects? You aren't going to avoid those issues by saying that
|
||
namespace == ownership is good enough.
|
||
|
||
I'm particularly troubled by the idea of trying to apply this "any"
|
||
lookup concept to resolution of overloaded operators and functions.
|
||
Suppose I have a reference func(type1,type2) that I'm trying to resolve,
|
||
and I have an inexact match (one requiring coercion) in my own schema.
|
||
Do I look to the "any" schema to see if there are better matches?
|
||
If so, what happens if the "any" schema contains multiple possibilities
|
||
with identical signatures (presumably created by different users)? ISTM
|
||
this will positively guarantee a resolution failure, since there's no
|
||
way for the resolver to prefer one over another. Thus, by creating
|
||
a "func(foo,bar)" function --- quite legally --- JRandomLuser might
|
||
break other people's formerly working queries that use other functions
|
||
named func. Although it's possible for this to happen now, it'll be
|
||
a lot more surprising if JRandomLuser thinks that his functions live
|
||
in his own private schema namespace.
|
||
|
||
I'm thinking that the overloading concept is not going to play well
|
||
at all with multiple namespaces for functions or operators, and that
|
||
we'd be best off to say that there is only one namespace (per database)
|
||
for these things.
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 6: Have you searched our list archives?
|
||
|
||
http://archives.postgresql.org
|
||
|
||
From pgsql-hackers-owner+M17998=candle.pha.pa.us=pgman@postgresql.org Tue Jan 22 19:33:10 2002
|
||
Return-path: <pgsql-hackers-owner+M17998=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0N0X9U02302
|
||
for <pgman@candle.pha.pa.us>; Tue, 22 Jan 2002 19:33:09 -0500 (EST)
|
||
Received: (qmail 52787 invoked by alias); 23 Jan 2002 00:33:08 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 00:33:08 -0000
|
||
Received: from ece.rice.edu (ece.rice.edu [128.42.4.34])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0N0IEl49263
|
||
for <pgsql-hackers@postgresql.org>; Tue, 22 Jan 2002 19:18:14 -0500 (EST)
|
||
(envelope-from reedstrm@rice.edu)
|
||
Received: from localhost (localhost [127.0.0.1])
|
||
by ece.rice.edu (Postfix) with ESMTP
|
||
id A57FF68A57; Tue, 22 Jan 2002 18:18:14 -0600 (CST)
|
||
Received: from wallace.ece.rice.edu (wallace.ece.rice.edu [128.42.12.154])
|
||
by ece.rice.edu (Postfix) with ESMTP
|
||
id 393F168A1D; Tue, 22 Jan 2002 18:18:13 -0600 (CST)
|
||
Received: from reedstrm by wallace.ece.rice.edu with local (Exim 3.22 #1 (Debian))
|
||
id 16TB7F-000292-00; Tue, 22 Jan 2002 18:18:13 -0600
|
||
Date: Tue, 22 Jan 2002 18:18:13 -0600
|
||
From: "Ross J. Reedstrom" <reedstrm@rice.edu>
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
Message-ID: <20020123001812.GB7932@rice.edu>
|
||
Mail-Followup-To: "Ross J. Reedstrom" <reedstrm@ece.rice.edu>,
|
||
Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
|
||
pgsql-hackers@postgresql.org
|
||
References: <Pine.LNX.4.30.0201221816130.686-100000@peter.localdomain> <29288.1011742268@sss.pgh.pa.us>
|
||
MIME-Version: 1.0
|
||
Content-Type: text/plain; charset=us-ascii
|
||
Content-Disposition: inline
|
||
In-Reply-To: <29288.1011742268@sss.pgh.pa.us>
|
||
User-Agent: Mutt/1.3.25i
|
||
X-Virus-Scanned: by AMaViS snapshot-20010714
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Tue, Jan 22, 2002 at 06:31:08PM -0500, Tom Lane wrote:
|
||
> Peter Eisentraut <peter_e@gmx.net> writes:
|
||
> > Moreover, I figure if we do it that
|
||
> > way, the whole schema implementation reduces itself mostly to parser work,
|
||
> > no complicated system catalog changes, no complex overhaul of the
|
||
> > privilege system -- at least initially.
|
||
>
|
||
> Why are you guys so eager to save me work? I'm not in the least
|
||
> interested in implementing a "schema" feature that can only handle
|
||
> the entry-level user == schema case. Therefore, just relabeling the
|
||
> owner column as schema isn't an interesting option.
|
||
>
|
||
> I really don't see what's wrong with building a namespace mechanism
|
||
> that is orthogonal to ownership and then using that to implement what
|
||
> SQL92 wants. I think this will be cleaner, simpler, and more flexible
|
||
> than trying to equate ownership with namespace.
|
||
>
|
||
|
||
I'm with Tom on this: the extended Schema capability he's described
|
||
combines the best of both authentication mechanisms, IMHO. It give
|
||
us namespace separation ala the SQL standard, and individual object
|
||
ownership, like unix FS semantics. Only having ownership on the
|
||
'containers' strikes me as limiting, even if that is how the standard
|
||
describes it.
|
||
|
||
Ross
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 4: Don't 'kill -9' the postmaster
|
||
|
||
From pgsql-hackers-owner+M18002=candle.pha.pa.us=pgman@postgresql.org Tue Jan 22 20:33:04 2002
|
||
Return-path: <pgsql-hackers-owner+M18002=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0N1X3U05117
|
||
for <pgman@candle.pha.pa.us>; Tue, 22 Jan 2002 20:33:03 -0500 (EST)
|
||
Received: (qmail 73320 invoked by alias); 23 Jan 2002 01:32:55 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 01:32:55 -0000
|
||
Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0N1FDl69103
|
||
for <pgsql-hackers@postgreSQL.org>; Tue, 22 Jan 2002 20:15:14 -0500 (EST)
|
||
(envelope-from wrstuden@netbsd.org)
|
||
Received: (qmail 12961 invoked by uid 1130); 23 Jan 2002 01:15:07 -0000
|
||
Date: Tue, 22 Jan 2002 17:10:24 -0800 (PST)
|
||
From: Bill Studenmund <wrstuden@netbsd.org>
|
||
X-X-Sender: <wrstuden@vespasia.home-net.internetconnect.net>
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <11381.1011648592@sss.pgh.pa.us>
|
||
Message-ID: <Pine.NEB.4.33.0201221657270.5119-100000@vespasia.home-net.internetconnect.net>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Mon, 21 Jan 2002, Tom Lane wrote:
|
||
|
||
> Continuing to think about implementing SQL schemas for 7.3 ...
|
||
>
|
||
> Today's topic for discussion: which types of Postgres objects should
|
||
> belong to schemas, and which ones should have other name scopes?
|
||
>
|
||
> Relations (tables, indexes, views, sequences) clearly belong to schemas.
|
||
> Since each relation has an associated datatype with the same name, it
|
||
> seems that datatypes must belong to schemas as well. (Even if that
|
||
> argument doesn't convince you, SQL99 says that user-defined datatypes
|
||
> belong to schemas.) However the situation is murkier for other kinds of
|
||
> objects.
|
||
>
|
||
> Here are all the kinds of named objects that exist in Postgres today,
|
||
> with some comments on whether they should belong to schemas or not:
|
||
>
|
||
> relations Must be in schemas
|
||
> types Must be in schemas
|
||
> databases Databases contain schemas, not vice versa
|
||
> users Users are cross-database, so not in schemas
|
||
> groups User groups are cross-database, so not in schemas
|
||
> languages Probably should not be in schemas
|
||
> access methods Probably should not be in schemas
|
||
> opclasses See below
|
||
> operators See below
|
||
> functions/procedures See below
|
||
> aggregates Should treat same as regular functions
|
||
> constraints See below
|
||
> rules See below
|
||
> triggers See below
|
||
> NOTIFY conditions See below
|
||
>
|
||
> Languages and access methods are not trivial to add to the system, so
|
||
> there's not much risk of name conflicts, and no reason to make their name
|
||
> scope less than global.
|
||
>
|
||
> The situation is a lot murkier for operators and functions. These should
|
||
> probably be treated alike, since operators are just syntactic sugar for
|
||
> functions. I think the basic argument for making them schema-local is
|
||
> that different users might conceivably want to define conflicting
|
||
> functions or operators of the same name. Against that, however, there
|
||
> are a number of reasons for wanting to keep these objects database-wide.
|
||
> First off there are syntactic problems. Do you really want to write
|
||
> A schemaname.+ B
|
||
> to qualify an ambiguous "+" operator? Looks way too much like a syntax
|
||
> error to me. Allowing this would probably turn a lot of simple syntax
|
||
> errors into things that get past the grammar and end up producing truly
|
||
> confusing error messages. Qualified function names also pose some
|
||
> problems, not so much with
|
||
> schemaname.function(args)
|
||
> which seems reasonable, but with the Berkeley-derived syntax that allows
|
||
> "foo.function" to mean "function(foo)" --- there's no way to squeeze a
|
||
> schema-name for the function into that. (And you'll recall from my note
|
||
|
||
Why not? What's wrong with either schema.foo.function (==>
|
||
function(schema.foo)) or foo.schema.function (==> schema.function(foo))?
|
||
Tables and functions can't have the same names as schemas, so we will be
|
||
able to notice the schema names in there. Oh, and I worked out how to get
|
||
parse.y to be happy with x.y & x.y.z (schema.package.function) names. :-)
|
||
|
||
> of the other day that we don't want to abandon this syntax entirely,
|
||
> because people would like us to support "sequencename.nextval" for Oracle
|
||
> compatibility.) Notice that we are not forced to make functions/operators
|
||
> schema-local just because datatypes are, because overloading will save the
|
||
> day. func(schema1.type1) and func(schema2.type1) are distinct functions
|
||
> because the types are different, even if they live in the same function
|
||
> namespace. Finally, SQL99 doesn't appear to think that operator and
|
||
> function names are schema-local; though that may just be because it hasn't
|
||
> got user-defined operators AFAICT.
|
||
|
||
Actually functions do have to be schema local. It's in the spec (don't
|
||
have exactly where with me).
|
||
|
||
> I am leaning towards keeping functions/operators database-wide, but would
|
||
> like to hear comments. Is there any real value in, eg, allowing different
|
||
> users to define different "+" operators *on the same datatypes*?
|
||
|
||
Yes. It means that third-party developers can develop routines and then
|
||
operators based on them without having to worry about conflicts. Obviously
|
||
these two different operators would have to be in different schemas. Also,
|
||
it would mean that someone could ship replacement operators for built-in
|
||
operators. Say adding a + operator which throws exceptions on overflow.
|
||
:-)
|
||
|
||
> Not sure about index opclasses. Given that datatype names are
|
||
> schema-local, one can think of scenarios where two users define similar
|
||
> datatypes and then try to use the same index opclass name for both.
|
||
> But it seems pretty unlikely. I'd prefer to leave opclass names
|
||
> database-wide for simplicity. Comments?
|
||
|
||
My vote would be to make them schema-specific. As Peter pointed out,
|
||
schemas are how you own things, so put them in a schema so we can keep
|
||
track of ownership.
|
||
|
||
Take care,
|
||
|
||
Bill
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
|
||
|
||
From pgsql-hackers-owner+M18001=candle.pha.pa.us=pgman@postgresql.org Tue Jan 22 20:23:11 2002
|
||
Return-path: <pgsql-hackers-owner+M18001=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0N1NAU04735
|
||
for <pgman@candle.pha.pa.us>; Tue, 22 Jan 2002 20:23:10 -0500 (EST)
|
||
Received: (qmail 70414 invoked by alias); 23 Jan 2002 01:23:01 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 01:23:01 -0000
|
||
Received: from corvette.mascari.com (dhcp065-024-158-068.columbus.rr.com [65.24.158.68])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0N1KBl69469
|
||
for <pgsql-hackers@postgresql.org>; Tue, 22 Jan 2002 20:20:11 -0500 (EST)
|
||
(envelope-from mascarm@mascari.com)
|
||
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
|
||
by corvette.mascari.com (8.9.3/8.9.3) with ESMTP id UAA30752
|
||
for <pgsql-hackers@postgresql.org>; Tue, 22 Jan 2002 20:15:29 -0500
|
||
Message-ID: <3C4E0EB1.1E3687FD@mascari.com>
|
||
Date: Tue, 22 Jan 2002 20:15:29 -0500
|
||
From: Mike Mascari <mascarm@mascari.com>
|
||
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
|
||
X-Accept-Language: en
|
||
MIME-Version: 1.0
|
||
To: pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
References: <Pine.LNX.4.30.0201221824360.686-100000@peter.localdomain> <29436.1011744140@sss.pgh.pa.us>
|
||
Content-Type: text/plain; charset=us-ascii
|
||
Content-Transfer-Encoding: 7bit
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Tom Lane wrote:
|
||
>
|
||
> I'm particularly troubled by the idea of trying to apply this "any"
|
||
> lookup concept to resolution of overloaded operators and functions.
|
||
> Suppose I have a reference func(type1,type2) that I'm trying to resolve,
|
||
> and I have an inexact match (one requiring coercion) in my own schema.
|
||
> Do I look to the "any" schema to see if there are better matches?
|
||
> If so, what happens if the "any" schema contains multiple possibilities
|
||
> with identical signatures (presumably created by different users)? ISTM
|
||
> this will positively guarantee a resolution failure, since there's no
|
||
> way for the resolver to prefer one over another. Thus, by creating
|
||
> a "func(foo,bar)" function --- quite legally --- JRandomLuser might
|
||
> break other people's formerly working queries that use other functions
|
||
> named func. Although it's possible for this to happen now, it'll be
|
||
> a lot more surprising if JRandomLuser thinks that his functions live
|
||
> in his own private schema namespace.
|
||
>
|
||
|
||
So, in a nutshell, the price we pay for function overloading is the
|
||
inability to have schema-specific functions. Right? Possibly why Oracle
|
||
doesn't allow function overloading? As a user, I'd much rather have
|
||
schema-specific functions than only global. I'm not downplaying the
|
||
value of function overloading, but if I had the choice (which I guess I
|
||
can't/won't), I'd choose schema-specific functions over function
|
||
overloading...
|
||
|
||
Mike Mascari
|
||
mascarm@mascari.com
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 6: Have you searched our list archives?
|
||
|
||
http://archives.postgresql.org
|
||
|
||
From pgsql-hackers-owner+M18003=candle.pha.pa.us=pgman@postgresql.org Tue Jan 22 20:52:52 2002
|
||
Return-path: <pgsql-hackers-owner+M18003=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0N1qqU05847
|
||
for <pgman@candle.pha.pa.us>; Tue, 22 Jan 2002 20:52:52 -0500 (EST)
|
||
Received: (qmail 76088 invoked by alias); 23 Jan 2002 01:52:50 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 01:52:50 -0000
|
||
Received: from student.gvsu.edu ([148.61.7.124])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0N1o8l75594
|
||
for <pgsql-hackers@postgreSQL.org>; Tue, 22 Jan 2002 20:50:08 -0500 (EST)
|
||
(envelope-from peter_e@gmx.net)
|
||
Received: from [148.61.250.147] [148.61.250.147] by student.gvsu.edu
|
||
with Novonyx SMTP Server $Revision: 1.3 $; Tue, 22 Jan 2002 20:50:13 -0500 (EDT)
|
||
Date: Tue, 22 Jan 2002 20:52:14 -0500 (EST)
|
||
From: Peter Eisentraut <peter_e@gmx.net>
|
||
X-Sender: <peter@peter.localdomain>
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <29288.1011742268@sss.pgh.pa.us>
|
||
Message-ID: <Pine.LNX.4.30.0201222042400.686-100000@peter.localdomain>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Tom Lane writes:
|
||
|
||
> I really don't see what's wrong with building a namespace mechanism
|
||
> that is orthogonal to ownership and then using that to implement what
|
||
> SQL92 wants. I think this will be cleaner, simpler, and more flexible
|
||
> than trying to equate ownership with namespace.
|
||
|
||
OK, I can accept that. But then I want to get back at my original point,
|
||
namely that all database objects (except users and groups) should be in
|
||
schemas. This is also cleaner, simpler, and more flexible. There is
|
||
clearly demand for schema-local functions. So I think that designing this
|
||
system from the premise that a schema-qualified operator call will look
|
||
strange is the wrong end to start at.
|
||
|
||
--
|
||
Peter Eisentraut peter_e@gmx.net
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 6: Have you searched our list archives?
|
||
|
||
http://archives.postgresql.org
|
||
|
||
From pgsql-hackers-owner+M18006=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 00:13:21 2002
|
||
Return-path: <pgsql-hackers-owner+M18006=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0N5DLU26660
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 00:13:21 -0500 (EST)
|
||
Received: (qmail 12536 invoked by alias); 23 Jan 2002 05:13:01 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 05:13:01 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0N58Cl11241
|
||
for <pgsql-hackers@postgreSQL.org>; Wed, 23 Jan 2002 00:08:12 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0N57vf00651;
|
||
Wed, 23 Jan 2002 00:07:58 -0500 (EST)
|
||
To: Bill Studenmund <wrstuden@netbsd.org>
|
||
cc: pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <Pine.NEB.4.33.0201221657270.5119-100000@vespasia.home-net.internetconnect.net>
|
||
References: <Pine.NEB.4.33.0201221657270.5119-100000@vespasia.home-net.internetconnect.net>
|
||
Comments: In-reply-to Bill Studenmund <wrstuden@netbsd.org>
|
||
message dated "Tue, 22 Jan 2002 17:10:24 -0800"
|
||
Date: Wed, 23 Jan 2002 00:07:57 -0500
|
||
Message-ID: <648.1011762477@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Bill Studenmund <wrstuden@netbsd.org> writes:
|
||
> Why not? What's wrong with either schema.foo.function (==>
|
||
> function(schema.foo)) or foo.schema.function (==> schema.function(foo))?
|
||
|
||
Neither is wrong in isolation, but how do you tell the difference?
|
||
More to the point, given input x.y.z, how do you tell which component
|
||
is what?
|
||
|
||
> Tables and functions can't have the same names as schemas,
|
||
|
||
News to me. Where is that written on stone tablets? Even if that's
|
||
considered an acceptable limitation from a purely functional point of
|
||
view, I don't like using it to disambiguate input. The error messages
|
||
you'll get from incorrect input to an implementation that depends on
|
||
that to disambiguate cases will not be very helpful.
|
||
|
||
> Actually functions do have to be schema local. It's in the spec (don't
|
||
> have exactly where with me).
|
||
|
||
(A) I don't believe that; please cite chapter and verse; (B) even if
|
||
SQL92 thinks that's okay, we can't do it that way because of
|
||
backwards-compatibility issues.
|
||
|
||
> My vote would be to make them schema-specific. As Peter pointed out,
|
||
> schemas are how you own things,
|
||
|
||
Sorry, but this line of argument is trying to assume the very point in
|
||
dispute.
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
|
||
|
||
From pgsql-hackers-owner+M18007=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 01:12:58 2002
|
||
Return-path: <pgsql-hackers-owner+M18007=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0N6CvU01868
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 01:12:57 -0500 (EST)
|
||
Received: (qmail 21084 invoked by alias); 23 Jan 2002 06:13:00 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 06:13:00 -0000
|
||
Received: from student.gvsu.edu ([148.61.7.124])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0N69Kl20384
|
||
for <pgsql-hackers@postgreSQL.org>; Wed, 23 Jan 2002 01:09:20 -0500 (EST)
|
||
(envelope-from peter_e@gmx.net)
|
||
Received: from [148.61.250.147] [148.61.250.147] by student.gvsu.edu
|
||
with Novonyx SMTP Server $Revision: 1.3 $; Wed, 23 Jan 2002 01:09:18 -0500 (EDT)
|
||
Date: Wed, 23 Jan 2002 01:11:21 -0500 (EST)
|
||
From: Peter Eisentraut <peter_e@gmx.net>
|
||
X-Sender: <peter@peter.localdomain>
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Bill Studenmund <wrstuden@netbsd.org>, <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <648.1011762477@sss.pgh.pa.us>
|
||
Message-ID: <Pine.LNX.4.30.0201230058150.686-100000@peter.localdomain>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Tom Lane writes:
|
||
|
||
> > Actually functions do have to be schema local. It's in the spec (don't
|
||
> > have exactly where with me).
|
||
>
|
||
> (A) I don't believe that; please cite chapter and verse;
|
||
|
||
In SQL99, chapter 4 verse 23 it says
|
||
|
||
"An SQL-invoked routine is an element of an SQL-schema and is called a
|
||
schema-level routine."
|
||
|
||
> (B) even if
|
||
> SQL92 thinks that's okay, we can't do it that way because of
|
||
> backwards-compatibility issues.
|
||
|
||
I don't buy that. If all you're looking for is preserving
|
||
|
||
foo.bar <==> bar(foo)
|
||
|
||
for compatibility, then you can simply say that "bar" cannot be
|
||
schema-qualified in the left form (so it needs to live in the current or
|
||
the default schema). We currently only have one default schema, so that's
|
||
backward compatible. I think this syntax is a mistake, so I don't feel
|
||
compelled to provide more than backwards compatibility.
|
||
|
||
--
|
||
Peter Eisentraut peter_e@gmx.net
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 3: if posting/reading through Usenet, please send an appropriate
|
||
subscribe-nomail command to majordomo@postgresql.org so that your
|
||
message can get through to the mailing list cleanly
|
||
|
||
From pgsql-hackers-owner+M18008=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 04:13:30 2002
|
||
Return-path: <pgsql-hackers-owner+M18008=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0N9DTU17316
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 04:13:29 -0500 (EST)
|
||
Received: (qmail 56495 invoked by alias); 23 Jan 2002 09:13:26 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 09:13:26 -0000
|
||
Received: from smxsat1.smxs.net (smxsat1.smxs.net [213.150.10.1])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0N9BKl55718
|
||
for <pgsql-hackers@postgresql.org>; Wed, 23 Jan 2002 04:11:21 -0500 (EST)
|
||
(envelope-from ZeugswetterA@spardat.at)
|
||
Received: from m01x1.s-mxs.net [10.3.55.201]
|
||
by smxsat1.smxs.net
|
||
with XWall v3.18f ;
|
||
Wed, 23 Jan 2002 10:12:42 +0100
|
||
Received: from m0102.s-mxs.net [10.3.55.2]
|
||
by m01x1.s-mxs.net
|
||
with XWall v3.18a ;
|
||
Wed, 23 Jan 2002 10:11:14 +0100
|
||
Received: from m0114.s-mxs.net ([10.3.55.14]) by m0102.s-mxs.net with Microsoft SMTPSVC(5.0.2195.2966);
|
||
Wed, 23 Jan 2002 10:11:13 +0100
|
||
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
|
||
content-class: urn:content-classes:message
|
||
MIME-Version: 1.0
|
||
Content-Type: text/plain;
|
||
charset="iso-8859-1"
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
Date: Wed, 23 Jan 2002 10:11:13 +0100
|
||
Message-ID: <46C15C39FEB2C44BA555E356FBCD6FA41EB4C2@m0114.s-mxs.net>
|
||
Thread-Topic: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
Thread-Index: AcGjixqphLJq/YpTSK6U7FZuNf4j3AAWxJvQ
|
||
From: "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
|
||
To: "Tom Lane" <tgl@sss.pgh.pa.us>, "Fernando Nasser" <fnasser@redhat.com>
|
||
cc: "Peter Eisentraut" <peter_e@gmx.net>, <pgsql-hackers@postgresql.org>
|
||
X-OriginalArrivalTime: 23 Jan 2002 09:11:13.0579 (UTC) FILETIME=[E7DEA7B0:01C1A3ED]
|
||
Content-Transfer-Encoding: 8bit
|
||
X-MIME-Autoconverted: from quoted-printable to 8bit by postgresql.org id g0N9CTm55809
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
|
||
> > Switches set to historical:
|
||
>
|
||
> > schema search path = (user's own schema, "any" schema, postgres)
|
||
>
|
||
> > [ default creation schema = user's own schema ]
|
||
>
|
||
> > The searching in "any" schema (i.e., any owner) will let will find
|
||
> > things that where defined the way they are today, i.e., possibly
|
||
> > by several different users.
|
||
>
|
||
> No, it won't, because nothing will ever get put into that schema.
|
||
> (At least not by existing pg_dump scripts, which are the things that
|
||
> really need to see the historical behavior.) The
|
||
> default-creation-schema variable has got to point at any/public/
|
||
> whatever-we-call it, or you do not have the historical behavior.
|
||
|
||
When configured for historical behavior would need to:
|
||
1. have search path: temp, any, system
|
||
2. guard against duplicate table names across all schemas (except temp schema)
|
||
|
||
Or are you thinking about a per session behavior ?
|
||
I would rather envision a per database behavior.
|
||
|
||
Maybe the easy way out would be a "default creation schema" property for
|
||
each user, that would default to the username. If you want everything in one
|
||
schema simply alter the users.
|
||
|
||
Andreas
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 5: Have you checked our extensive FAQ?
|
||
|
||
http://www.postgresql.org/users-lounge/docs/faq.html
|
||
|
||
From pgsql-hackers-owner+M18010=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 05:03:10 2002
|
||
Return-path: <pgsql-hackers-owner+M18010=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0NA39U22271
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 05:03:09 -0500 (EST)
|
||
Received: (qmail 70600 invoked by alias); 23 Jan 2002 10:03:04 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 10:03:04 -0000
|
||
Received: from smxsat1.smxs.net (smxsat1.smxs.net [213.150.10.1])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0N9xNl69597
|
||
for <pgsql-hackers@postgresql.org>; Wed, 23 Jan 2002 04:59:24 -0500 (EST)
|
||
(envelope-from ZeugswetterA@spardat.at)
|
||
Received: from m01x1.s-mxs.net [10.3.55.201]
|
||
by smxsat1.smxs.net
|
||
with XWall v3.18f ;
|
||
Wed, 23 Jan 2002 11:00:47 +0100
|
||
Received: from m0103.s-mxs.net [10.3.55.3]
|
||
by m01x1.s-mxs.net
|
||
with XWall v3.18a ;
|
||
Wed, 23 Jan 2002 10:59:19 +0100
|
||
Received: from m0114.s-mxs.net ([10.3.55.14]) by m0103.s-mxs.net with Microsoft SMTPSVC(5.0.2195.2966);
|
||
Wed, 23 Jan 2002 10:59:18 +0100
|
||
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
|
||
content-class: urn:content-classes:message
|
||
MIME-Version: 1.0
|
||
Content-Type: text/plain;
|
||
charset="iso-8859-1"
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
Date: Wed, 23 Jan 2002 10:59:18 +0100
|
||
Message-ID: <46C15C39FEB2C44BA555E356FBCD6FA42128DA@m0114.s-mxs.net>
|
||
Thread-Topic: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
Thread-Index: AcGj1QtRzBpAfJVfQjCydtlooB5fgwAHyaDQ
|
||
From: "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
|
||
To: "Peter Eisentraut" <peter_e@gmx.net>, "Tom Lane" <tgl@sss.pgh.pa.us>
|
||
cc: "Bill Studenmund" <wrstuden@netbsd.org>, <pgsql-hackers@postgresql.org>
|
||
X-OriginalArrivalTime: 23 Jan 2002 09:59:18.0969 (UTC) FILETIME=[9FB23A90:01C1A3F4]
|
||
Content-Transfer-Encoding: 8bit
|
||
X-MIME-Autoconverted: from quoted-printable to 8bit by postgresql.org id g0NA2d170062
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
|
||
> I don't buy that. If all you're looking for is preserving
|
||
>
|
||
> foo.bar <==> bar(foo)
|
||
>
|
||
> for compatibility, then you can simply say that "bar" cannot be
|
||
> schema-qualified in the left form (so it needs to live in the current or
|
||
> the default schema). We currently only have one default schema, so that's
|
||
> backward compatible. I think this syntax is a mistake, so I don't feel
|
||
> compelled to provide more than backwards compatibility.
|
||
|
||
This syntax is actually my favorite :-) I use it heavily for calculated
|
||
columns. I don't feel it is a mistake.
|
||
|
||
Andreas
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 6: Have you searched our list archives?
|
||
|
||
http://archives.postgresql.org
|
||
|
||
From pgsql-hackers-owner+M18012=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 06:13:40 2002
|
||
Return-path: <pgsql-hackers-owner+M18012=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0NBDdU21327
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 06:13:39 -0500 (EST)
|
||
Received: (qmail 81930 invoked by alias); 23 Jan 2002 11:13:12 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 11:13:12 -0000
|
||
Received: from mail_exchange.westcountrypublications.co.uk ([195.171.163.135])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0NB70l80597
|
||
for <pgsql-hackers@postgresql.org>; Wed, 23 Jan 2002 06:07:02 -0500 (EST)
|
||
(envelope-from SHenshall@westcountrypublications.co.uk)
|
||
Received: by MAIL_EXCHANGE with Internet Mail Service (5.5.2650.21)
|
||
id <DKQFH0AY>; Wed, 23 Jan 2002 11:03:18 -0000
|
||
Message-ID: <E2870D8CE1CCD311BAF50008C71EDE8E01F747A1@MAIL_EXCHANGE>
|
||
From: "Henshall, Stuart - WCP" <SHenshall@westcountrypublications.co.uk>
|
||
To: "'Tom Lane'" <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>
|
||
cc: Fernando Nasser <fnasser@redhat.com>, pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
Date: Wed, 23 Jan 2002 11:03:16 -0000
|
||
MIME-Version: 1.0
|
||
X-Mailer: Internet Mail Service (5.5.2650.21)
|
||
Content-Type: text/plain;
|
||
charset="iso-8859-1"
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
|
||
|
||
> -----Original Message-----
|
||
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
|
||
> Sent: 23 January 2002 00:02
|
||
> To: Peter Eisentraut
|
||
> Cc: Fernando Nasser; pgsql-hackers@postgresql.org
|
||
> Subject: Re: RFD: schemas and different kinds of Postgres objects
|
||
>
|
||
>
|
||
> Peter Eisentraut <peter_e@gmx.net> writes:
|
||
> > Tom Lane writes:
|
||
> >> No, it doesn't work the same as today, because in that
|
||
> implementation
|
||
> >> both A and B can create the same tablename without
|
||
> complaint. It then
|
||
> >> becomes very unclear which instance other people will get
|
||
> (unless your
|
||
> >> "any" placeholder somehow implies a search order).
|
||
>
|
||
> > The "search any schema" switch is only intended for use with legacy
|
||
> > databases, where duplicate names don't occur anyway.
|
||
>
|
||
> That's a mighty narrow view of the world. Do you think that
|
||
> people had
|
||
> better convert to SQL schemas before they ever again create a table?
|
||
> The fact is that ordinary non-schema-aware usage will
|
||
> certainly lead to
|
||
> the above scenario.
|
||
>
|
||
> > that the switch probably doesn't make a whole lot of sense.
|
||
> However, to
|
||
> > get reproduceable behaviour anyway we can just define a
|
||
> search order, such
|
||
> > as by schema name.
|
||
>
|
||
> Or say that you get an "ambiguous reference" error if there
|
||
> is more than
|
||
> one possible candidate in the "any" namespace. (Although
|
||
> that opens the
|
||
> door for innocent creation of a table foo by one user to break other
|
||
> people's formerly-working queries that reference some other foo.)
|
||
> Bottom line for me is that this is an untried concept. I think the
|
||
> concept of an "any" searchlist entry is risky enough that I don't much
|
||
> want to hang the entire usability of the implementation on the
|
||
> assumption that we won't find any fatal problems with "any".
|
||
>
|
||
>
|
||
> However, the argument over whether SQL92's concept of ownership should
|
||
> be taken as gospel is not really the argument I wanted to have in this
|
||
> thread. Is it possible to go back to the original point concerning
|
||
> whether there should be different namespace boundaries for different
|
||
> types of objects? You aren't going to avoid those issues by
|
||
> saying that
|
||
> namespace == ownership is good enough.
|
||
>
|
||
> I'm particularly troubled by the idea of trying to apply this "any"
|
||
> lookup concept to resolution of overloaded operators and functions.
|
||
> Suppose I have a reference func(type1,type2) that I'm trying
|
||
> to resolve,
|
||
> and I have an inexact match (one requiring coercion) in my own schema.
|
||
> Do I look to the "any" schema to see if there are better matches?
|
||
> If so, what happens if the "any" schema contains multiple
|
||
> possibilities
|
||
> with identical signatures (presumably created by different
|
||
> users)? ISTM
|
||
> this will positively guarantee a resolution failure, since there's no
|
||
> way for the resolver to prefer one over another. Thus, by creating
|
||
> a "func(foo,bar)" function --- quite legally --- JRandomLuser might
|
||
> break other people's formerly working queries that use other functions
|
||
> named func. Although it's possible for this to happen now, it'll be
|
||
> a lot more surprising if JRandomLuser thinks that his functions live
|
||
> in his own private schema namespace.
|
||
>
|
||
> I'm thinking that the overloading concept is not going to play well
|
||
> at all with multiple namespaces for functions or operators, and that
|
||
> we'd be best off to say that there is only one namespace (per
|
||
> database)
|
||
> for these things.
|
||
>
|
||
> regards, tom lane
|
||
>
|
||
Could you just have a general rule of search in order of age (by OID)? This
|
||
should prevent changes to existing operation when new definitions come along
|
||
(unless new definition is in new own schema or default).
|
||
Cheers,
|
||
- Stuart
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 4: Don't 'kill -9' the postmaster
|
||
|
||
From pgsql-hackers-owner+M18024=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 10:13:55 2002
|
||
Return-path: <pgsql-hackers-owner+M18024=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0NFDsU06028
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 10:13:54 -0500 (EST)
|
||
Received: (qmail 39657 invoked by alias); 23 Jan 2002 15:13:28 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 15:13:28 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0NF1dl35283
|
||
for <pgsql-hackers@postgresql.org>; Wed, 23 Jan 2002 10:01:40 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0NExef02480;
|
||
Wed, 23 Jan 2002 09:59:40 -0500 (EST)
|
||
To: "Henshall, Stuart - WCP" <SHenshall@westcountrypublications.co.uk>
|
||
cc: Peter Eisentraut <peter_e@gmx.net>, Fernando Nasser <fnasser@redhat.com>,
|
||
pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <E2870D8CE1CCD311BAF50008C71EDE8E01F747A1@MAIL_EXCHANGE>
|
||
References: <E2870D8CE1CCD311BAF50008C71EDE8E01F747A1@MAIL_EXCHANGE>
|
||
Comments: In-reply-to "Henshall, Stuart - WCP" <SHenshall@westcountrypublications.co.uk>
|
||
message dated "Wed, 23 Jan 2002 11:03:16 +0000"
|
||
Date: Wed, 23 Jan 2002 09:59:39 -0500
|
||
Message-ID: <2477.1011797979@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
"Henshall, Stuart - WCP" <SHenshall@westcountrypublications.co.uk> writes:
|
||
> Could you just have a general rule of search in order of age (by OID)?
|
||
|
||
No, unless you plan to abandon the whole notion of resolving ambiguous
|
||
operator/function calls. (Which'd cut down our TODO list a good bit ;-)
|
||
but I don't think users would be happy...) OID/age ordering generally
|
||
has little to do with reasonable resolution behavior.
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 3: if posting/reading through Usenet, please send an appropriate
|
||
subscribe-nomail command to majordomo@postgresql.org so that your
|
||
message can get through to the mailing list cleanly
|
||
|
||
From pgsql-hackers-owner+M18026=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 10:33:35 2002
|
||
Return-path: <pgsql-hackers-owner+M18026=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0NFXYU07736
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 10:33:34 -0500 (EST)
|
||
Received: (qmail 44416 invoked by alias); 23 Jan 2002 15:33:29 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 15:33:29 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0NFVfl43926
|
||
for <pgsql-hackers@postgreSQL.org>; Wed, 23 Jan 2002 10:31:41 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0NFVQf02603;
|
||
Wed, 23 Jan 2002 10:31:26 -0500 (EST)
|
||
To: Peter Eisentraut <peter_e@gmx.net>
|
||
cc: pgsql-hackers@postgresql.org, Fernando Nasser <fnasser@redhat.com>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <Pine.LNX.4.30.0201222042400.686-100000@peter.localdomain>
|
||
References: <Pine.LNX.4.30.0201222042400.686-100000@peter.localdomain>
|
||
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
|
||
message dated "Tue, 22 Jan 2002 20:52:14 -0500"
|
||
Date: Wed, 23 Jan 2002 10:31:25 -0500
|
||
Message-ID: <2600.1011799885@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Peter Eisentraut <peter_e@gmx.net> writes:
|
||
> OK, I can accept that. But then I want to get back at my original point,
|
||
> namely that all database objects (except users and groups) should be in
|
||
> schemas. This is also cleaner, simpler, and more flexible. There is
|
||
> clearly demand for schema-local functions. So I think that designing this
|
||
> system from the premise that a schema-qualified operator call will look
|
||
> strange is the wrong end to start at.
|
||
|
||
Okay, a fair point --- or you could have used my own argument against
|
||
me: there's nothing wrong with designing a general mechanism and then
|
||
choosing not to expose all of the functionality. So let's assume that
|
||
functions and operators live in namespaces, and that we have some kind
|
||
of search path across multiple namespaces for use when an unqualified
|
||
name is given.
|
||
|
||
Now, how is that going to play with resolution of ambiguous calls?
|
||
|
||
The most reasonable semantics I can think of are to collect all the
|
||
potential matches (matching op/func name) across all the searchable
|
||
namespaces, discarding only those that have exactly the same signature
|
||
as one in a prior namespace. Thus, eg, plus(int4,int4) in an earlier
|
||
namespace would hide plus(int4,int4) in a later namespace in the search
|
||
path, but it wouldn't hide plus(int8,int8). After we've collected all
|
||
the visible alternatives, do resolution based on argument types the same
|
||
way as we do now.
|
||
|
||
The only alternative semantics that seem defensible at all are to stop
|
||
at the first namespace that contains any matching-by-name op or func,
|
||
and do resolution using only the candidates available in that namespace.
|
||
That strikes me as not a good idea; for example, a user who defines a
|
||
"+" operator in his own schema for his own datatype would be quite
|
||
unhappy to find it masking all the "+" operators in the system schema.
|
||
|
||
I believe that this behavior would be fairly reasonable if our
|
||
backward-compatibility feature consists of a "public" namespace
|
||
that all users can write in. OTOH I think it would not play at all
|
||
well if we use Fernando's idea of an "any" wildcard in the search
|
||
path. (1) Imagine the case where we have some users who are using
|
||
the backward-compatible behavior while others have set up private
|
||
namespaces. If Joe SmartGuy creates a "+" operator in his private
|
||
namespace, it'll be visible to people using the "any" wildcard and
|
||
possibly cause resolution-ambiguity failures for them, even though
|
||
Joe deliberately did what he should do to avoid that. (2) "any"
|
||
creates the problem of resolving multiple functions with identical
|
||
signatures in different namespaces, with no reasonable rule for
|
||
making the choice.
|
||
|
||
So I'm still of the opinion that an "any" wildcard is too risky a
|
||
solution for our backwards-compatibility problem.
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 4: Don't 'kill -9' the postmaster
|
||
|
||
From pgsql-hackers-owner+M18030=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 11:35:41 2002
|
||
Return-path: <pgsql-hackers-owner+M18030=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0NGZeU13512
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 11:35:40 -0500 (EST)
|
||
Received: (qmail 91981 invoked by alias); 23 Jan 2002 16:34:06 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 16:34:06 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0NFjNl67457
|
||
for <pgsql-hackers@postgresql.org>; Wed, 23 Jan 2002 10:45:58 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0NFiYf02680;
|
||
Wed, 23 Jan 2002 10:44:34 -0500 (EST)
|
||
To: "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
|
||
cc: "Fernando Nasser" <fnasser@redhat.com>,
|
||
"Peter Eisentraut" <peter_e@gmx.net>, pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <46C15C39FEB2C44BA555E356FBCD6FA41EB4C2@m0114.s-mxs.net>
|
||
References: <46C15C39FEB2C44BA555E356FBCD6FA41EB4C2@m0114.s-mxs.net>
|
||
Comments: In-reply-to "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
|
||
message dated "Wed, 23 Jan 2002 10:11:13 +0100"
|
||
Date: Wed, 23 Jan 2002 10:44:34 -0500
|
||
Message-ID: <2677.1011800674@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: ORr
|
||
|
||
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
|
||
> When configured for historical behavior would need to:
|
||
> 1. have search path: temp, any, system
|
||
> 2. guard against duplicate table names across all schemas (except temp schema)
|
||
|
||
This would be a *whole* lot simpler if we forgot the notion of "any"
|
||
and made the search order look like
|
||
|
||
(temp, private, public, system)
|
||
|
||
where the public namespace is world-writable but the private per-user
|
||
ones are (typically at least) not.
|
||
|
||
It occurs to me that we can get both backward-compatible and SQL92
|
||
semantics with this same search path; the only thing that needs to
|
||
be different in the two cases is whether the default place to create
|
||
objects is your private schema or the public one. If you don't ever
|
||
use your private schema then it doesn't matter if it's on the search
|
||
path or not. I would still prefer that the search path be a settable
|
||
option, since a paranoid person might well wish to not have public in
|
||
his path at all ... but the default could be as-above.
|
||
|
||
> Or are you thinking about a per session behavior ?
|
||
> I would rather envision a per database behavior.
|
||
> Maybe the easy way out would be a "default creation schema" property for
|
||
> each user, that would default to the username. If you want everything in one
|
||
> schema simply alter the users.
|
||
|
||
I hadn't really gotten to the point of thinking about exactly what and
|
||
where the control knobs should be. I suspect you are right that we will
|
||
want the default behavior to be selectable on a per-user or per-database
|
||
basis, which seems to eliminate the option of using GUC (at least in its
|
||
current form). We could easily add a field to pg_shadow or pg_database
|
||
respectively to determine the default behavior. It'd be nice though if
|
||
the behavior could be changed after connection by a SET statement, which
|
||
would be lots easier if the setting were GUC-controlled. Peter, you see
|
||
any way to resolve that?
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 3: if posting/reading through Usenet, please send an appropriate
|
||
subscribe-nomail command to majordomo@postgresql.org so that your
|
||
message can get through to the mailing list cleanly
|
||
|
||
From pgsql-hackers-owner+M18034=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 11:50:22 2002
|
||
Return-path: <pgsql-hackers-owner+M18034=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0NGoLU15032
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 11:50:21 -0500 (EST)
|
||
Received: (qmail 1716 invoked by alias); 23 Jan 2002 16:50:05 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 16:50:05 -0000
|
||
Received: from megazone.bigpanda.com (megazone.bigpanda.com [63.150.15.178])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0NGZgl93351
|
||
for <pgsql-hackers@postgreSQL.org>; Wed, 23 Jan 2002 11:35:42 -0500 (EST)
|
||
(envelope-from sszabo@megazone23.bigpanda.com)
|
||
Received: by megazone.bigpanda.com (Postfix, from userid 1001)
|
||
id ABA27D5E5; Wed, 23 Jan 2002 08:35:47 -0800 (PST)
|
||
Received: from localhost (localhost [127.0.0.1])
|
||
by megazone.bigpanda.com (Postfix) with ESMTP
|
||
id 9D3E55BF5; Wed, 23 Jan 2002 08:35:47 -0800 (PST)
|
||
Date: Wed, 23 Jan 2002 08:35:47 -0800 (PST)
|
||
From: Stephan Szabo <sszabo@megazone23.bigpanda.com>
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Peter Eisentraut <peter_e@gmx.net>, <pgsql-hackers@postgresql.org>,
|
||
Fernando Nasser <fnasser@redhat.com>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <2600.1011799885@sss.pgh.pa.us>
|
||
Message-ID: <20020123083152.W18169-100000@megazone23.bigpanda.com>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
|
||
On Wed, 23 Jan 2002, Tom Lane wrote:
|
||
|
||
> The only alternative semantics that seem defensible at all are to stop
|
||
> at the first namespace that contains any matching-by-name op or func,
|
||
> and do resolution using only the candidates available in that namespace.
|
||
> That strikes me as not a good idea; for example, a user who defines a
|
||
> "+" operator in his own schema for his own datatype would be quite
|
||
> unhappy to find it masking all the "+" operators in the system schema.
|
||
>
|
||
> I believe that this behavior would be fairly reasonable if our
|
||
> backward-compatibility feature consists of a "public" namespace
|
||
> that all users can write in. OTOH I think it would not play at all
|
||
> well if we use Fernando's idea of an "any" wildcard in the search
|
||
> path. (1) Imagine the case where we have some users who are using
|
||
> the backward-compatible behavior while others have set up private
|
||
> namespaces. If Joe SmartGuy creates a "+" operator in his private
|
||
> namespace, it'll be visible to people using the "any" wildcard and
|
||
> possibly cause resolution-ambiguity failures for them, even though
|
||
> Joe deliberately did what he should do to avoid that. (2) "any"
|
||
> creates the problem of resolving multiple functions with identical
|
||
> signatures in different namespaces, with no reasonable rule for
|
||
> making the choice.
|
||
|
||
Wouldn't it make sense to prefer operators/functions earlier in the search
|
||
path for resolving ambiguity. So if you had plus(int4, int4) in my
|
||
schema and plus(int8, int8) in system, and they'd otherwise cause an
|
||
ambiguity failure for the query, use the plus(int4, int4) on mine. It
|
||
seems not too far from having the search path shadow later exact matches.
|
||
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 4: Don't 'kill -9' the postmaster
|
||
|
||
From pgsql-hackers-owner+M18041=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 12:18:50 2002
|
||
Return-path: <pgsql-hackers-owner+M18041=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0NHInU20563
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 12:18:49 -0500 (EST)
|
||
Received: (qmail 17817 invoked by alias); 23 Jan 2002 17:14:34 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 17:14:34 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0NHC6l15615
|
||
for <pgsql-hackers@postgreSQL.org>; Wed, 23 Jan 2002 12:12:06 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0NGkwf03162;
|
||
Wed, 23 Jan 2002 11:46:58 -0500 (EST)
|
||
To: Stephan Szabo <sszabo@megazone23.bigpanda.com>
|
||
cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org,
|
||
Fernando Nasser <fnasser@redhat.com>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <20020123083152.W18169-100000@megazone23.bigpanda.com>
|
||
References: <20020123083152.W18169-100000@megazone23.bigpanda.com>
|
||
Comments: In-reply-to Stephan Szabo <sszabo@megazone23.bigpanda.com>
|
||
message dated "Wed, 23 Jan 2002 08:35:47 -0800"
|
||
Date: Wed, 23 Jan 2002 11:46:58 -0500
|
||
Message-ID: <3159.1011804418@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Stephan Szabo <sszabo@megazone23.bigpanda.com> writes:
|
||
> Wouldn't it make sense to prefer operators/functions earlier in the search
|
||
> path for resolving ambiguity. So if you had plus(int4, int4) in my
|
||
> schema and plus(int8, int8) in system, and they'd otherwise cause an
|
||
> ambiguity failure for the query, use the plus(int4, int4) on mine. It
|
||
> seems not too far from having the search path shadow later exact matches.
|
||
|
||
Given the complexity of the resolution rules (cf.
|
||
http://developer.postgresql.org/docs/postgres/typeconv.html),
|
||
it's not clear that we can determine exactly which "later" entry ought
|
||
to be blamed for causing a resolution failure. I'd be interested to
|
||
hear Lockhart's opinion on this --- but my gut feeling is we don't
|
||
want to go there. The resolution rules are already complicated enough,
|
||
and I think layering an additional mechanism like that onto them might
|
||
make the behavior totally unpredictable.
|
||
|
||
Another problem is that this would probably cause earlier namespace
|
||
entries to be over-preferred. For example, suppose that the system
|
||
namespace has plus(int4,int4) and plus(int8,int8) and you choose to
|
||
define plus(int4,int8) locally. I believe you'd suddenly find yours
|
||
being used for *any* cross-datatype addition, including cases that
|
||
had nothing obvious to do with either int4 or int8 ...
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
|
||
|
||
From pgsql-hackers-owner+M18040=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 12:18:51 2002
|
||
Return-path: <pgsql-hackers-owner+M18040=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0NHIoU20594
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 12:18:51 -0500 (EST)
|
||
Received: (qmail 17832 invoked by alias); 23 Jan 2002 17:14:34 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 17:14:34 -0000
|
||
Received: from mx1.relaypoint.net (ns2.generalbroadband.com [64.32.62.5])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0NGu6l05540
|
||
for <pgsql-hackers@postgresql.org>; Wed, 23 Jan 2002 11:56:06 -0500 (EST)
|
||
(envelope-from jconway@cox.net)
|
||
Received: from [206.19.64.3] (account jconway@wwc.com HELO cox.net)
|
||
by mx1.relaypoint.net (CommuniGate Pro SMTP 3.4.8)
|
||
with ESMTP id 2510369; Wed, 23 Jan 2002 08:56:10 -0800
|
||
Message-ID: <3C4EEB2F.8040803@cox.net>
|
||
Date: Wed, 23 Jan 2002 08:56:15 -0800
|
||
From: "Joe Conway (wwc)" <jconway@cox.net>
|
||
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6+) Gecko/20011219
|
||
X-Accept-Language: en-us
|
||
MIME-Version: 1.0
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Zeugswetter Andreas SB SD <ZeugswetterA@spardat.at>,
|
||
Fernando Nasser <fnasser@redhat.com>, Peter Eisentraut <peter_e@gmx.net>,
|
||
pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
References: <46C15C39FEB2C44BA555E356FBCD6FA41EB4C2@m0114.s-mxs.net> <2677.1011800674@sss.pgh.pa.us>
|
||
Content-Type: text/plain; charset=us-ascii; format=flowed
|
||
Content-Transfer-Encoding: 7bit
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Tom Lane wrote:
|
||
|
||
>
|
||
> This would be a *whole* lot simpler if we forgot the notion of "any"
|
||
> and made the search order look like
|
||
>
|
||
> (temp, private, public, system)
|
||
>
|
||
> where the public namespace is world-writable but the private per-user
|
||
> ones are (typically at least) not.
|
||
>
|
||
> It occurs to me that we can get both backward-compatible and SQL92
|
||
> semantics with this same search path; the only thing that needs to
|
||
> be different in the two cases is whether the default place to create
|
||
> objects is your private schema or the public one. If you don't ever
|
||
> use your private schema then it doesn't matter if it's on the search
|
||
> path or not. I would still prefer that the search path be a settable
|
||
> option, since a paranoid person might well wish to not have public in
|
||
> his path at all ... but the default could be as-above.
|
||
>
|
||
|
||
|
||
I think it would be desirable to be able to restrict users from
|
||
"publishing" objects into the public schema. As an admin, I'd like some
|
||
control over the objects in this namespace. Hand-in-hand with this would
|
||
be the ability for the superuser to move (or "promote") an object from a
|
||
private schema to the public one. This would allow a user to develop
|
||
their own objects without interfering with others, but then make it
|
||
public with the superuser's assistance.
|
||
|
||
The search path you suggest above would then lead to the behavior that
|
||
unqualified references to objects will see my own objects before the
|
||
public ones, and other people's private objects must be explicitly
|
||
qualified.
|
||
|
||
Joe
|
||
|
||
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 6: Have you searched our list archives?
|
||
|
||
http://archives.postgresql.org
|
||
|
||
From pgsql-hackers-owner+M18042=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 12:18:45 2002
|
||
Return-path: <pgsql-hackers-owner+M18042=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0NHIiU20532
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 12:18:45 -0500 (EST)
|
||
Received: (qmail 17765 invoked by alias); 23 Jan 2002 17:14:31 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 17:14:31 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0NH1Tl11512
|
||
for <pgsql-hackers@postgresql.org>; Wed, 23 Jan 2002 12:01:29 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0NH0vf03329;
|
||
Wed, 23 Jan 2002 12:00:57 -0500 (EST)
|
||
To: "Joe Conway (wwc)" <jconway@cox.net>
|
||
cc: Zeugswetter Andreas SB SD <ZeugswetterA@spardat.at>,
|
||
Fernando Nasser <fnasser@redhat.com>, Peter Eisentraut <peter_e@gmx.net>,
|
||
pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <3C4EEB2F.8040803@cox.net>
|
||
References: <46C15C39FEB2C44BA555E356FBCD6FA41EB4C2@m0114.s-mxs.net> <2677.1011800674@sss.pgh.pa.us> <3C4EEB2F.8040803@cox.net>
|
||
Comments: In-reply-to "Joe Conway (wwc)" <jconway@cox.net>
|
||
message dated "Wed, 23 Jan 2002 08:56:15 -0800"
|
||
Date: Wed, 23 Jan 2002 12:00:56 -0500
|
||
Message-ID: <3326.1011805256@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
"Joe Conway (wwc)" <jconway@cox.net> writes:
|
||
> I think it would be desirable to be able to restrict users from
|
||
> "publishing" objects into the public schema.
|
||
|
||
Sure. I'm envisioning that namespaces will have ACLs --- that's what
|
||
will keep private namespaces private. So, while public would by default
|
||
be world-writable (at least in the backwards-compatibility case),
|
||
there'd be nothing stopping you from marking it as read-only to some
|
||
users.
|
||
|
||
Come to think of it, that's still another reason not to have an "any"
|
||
wildcard: there's no way to put any restrictions on what appears in
|
||
such a namespace.
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 6: Have you searched our list archives?
|
||
|
||
http://archives.postgresql.org
|
||
|
||
From pgsql-hackers-owner+M18043=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 12:22:29 2002
|
||
Return-path: <pgsql-hackers-owner+M18043=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0NHMSU21118
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 12:22:28 -0500 (EST)
|
||
Received: (qmail 17648 invoked by alias); 23 Jan 2002 17:14:27 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 17:14:27 -0000
|
||
Received: from megazone.bigpanda.com (megazone.bigpanda.com [63.150.15.178])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0NH9Ul15308
|
||
for <pgsql-hackers@postgreSQL.org>; Wed, 23 Jan 2002 12:09:30 -0500 (EST)
|
||
(envelope-from sszabo@megazone23.bigpanda.com)
|
||
Received: by megazone.bigpanda.com (Postfix, from userid 1001)
|
||
id E7DB9D5E5; Wed, 23 Jan 2002 09:09:35 -0800 (PST)
|
||
Received: from localhost (localhost [127.0.0.1])
|
||
by megazone.bigpanda.com (Postfix) with ESMTP
|
||
id DD82F5BF5; Wed, 23 Jan 2002 09:09:35 -0800 (PST)
|
||
Date: Wed, 23 Jan 2002 09:09:35 -0800 (PST)
|
||
From: Stephan Szabo <sszabo@megazone23.bigpanda.com>
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Peter Eisentraut <peter_e@gmx.net>, <pgsql-hackers@postgresql.org>,
|
||
Fernando Nasser <fnasser@redhat.com>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <3159.1011804418@sss.pgh.pa.us>
|
||
Message-ID: <20020123085959.U18688-100000@megazone23.bigpanda.com>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
|
||
On Wed, 23 Jan 2002, Tom Lane wrote:
|
||
|
||
> Stephan Szabo <sszabo@megazone23.bigpanda.com> writes:
|
||
> > Wouldn't it make sense to prefer operators/functions earlier in the search
|
||
> > path for resolving ambiguity. So if you had plus(int4, int4) in my
|
||
> > schema and plus(int8, int8) in system, and they'd otherwise cause an
|
||
> > ambiguity failure for the query, use the plus(int4, int4) on mine. It
|
||
> > seems not too far from having the search path shadow later exact matches.
|
||
>
|
||
> Given the complexity of the resolution rules (cf.
|
||
> http://developer.postgresql.org/docs/postgres/typeconv.html),
|
||
> it's not clear that we can determine exactly which "later" entry ought
|
||
> to be blamed for causing a resolution failure. I'd be interested to
|
||
> hear Lockhart's opinion on this --- but my gut feeling is we don't
|
||
> want to go there. The resolution rules are already complicated enough,
|
||
> and I think layering an additional mechanism like that onto them might
|
||
> make the behavior totally unpredictable.
|
||
|
||
> Another problem is that this would probably cause earlier namespace
|
||
> entries to be over-preferred. For example, suppose that the system
|
||
> namespace has plus(int4,int4) and plus(int8,int8) and you choose to
|
||
> define plus(int4,int8) locally. I believe you'd suddenly find yours
|
||
> being used for *any* cross-datatype addition, including cases that
|
||
> had nothing obvious to do with either int4 or int8 ...
|
||
|
||
Well, what I'd been thinking of would have been similar to anywhere it
|
||
says "If only one candidate matches", becoming "If the earliest search
|
||
path entry with at least one candidate matching has only one
|
||
matching candidate ..." But that would cause the plus(int4, int8) to get
|
||
used in any cross-datatype case that could coerce and didn't have a
|
||
stronger match (ie, one of the arguments exactly matching a plus argument
|
||
per b or c) so that's probably not good enough.
|
||
|
||
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 3: if posting/reading through Usenet, please send an appropriate
|
||
subscribe-nomail command to majordomo@postgresql.org so that your
|
||
message can get through to the mailing list cleanly
|
||
|
||
From pgsql-hackers-owner+M18058=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 14:45:20 2002
|
||
Return-path: <pgsql-hackers-owner+M18058=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0NJjJU03694
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 14:45:19 -0500 (EST)
|
||
Received: (qmail 89208 invoked by alias); 23 Jan 2002 19:43:44 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 19:43:44 -0000
|
||
Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0NJd7l87615
|
||
for <pgsql-hackers@postgreSQL.org>; Wed, 23 Jan 2002 14:39:07 -0500 (EST)
|
||
(envelope-from wrstuden@netbsd.org)
|
||
Received: (qmail 11757 invoked by uid 1130); 23 Jan 2002 19:39:07 -0000
|
||
Date: Wed, 23 Jan 2002 11:34:23 -0800 (PST)
|
||
From: Bill Studenmund <wrstuden@netbsd.org>
|
||
X-X-Sender: <wrstuden@vespasia.home-net.internetconnect.net>
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Peter Eisentraut <peter_e@gmx.net>, <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <12239.1011661590@sss.pgh.pa.us>
|
||
Message-ID: <Pine.NEB.4.33.0201221710360.5119-100000@vespasia.home-net.internetconnect.net>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Mon, 21 Jan 2002, Tom Lane wrote:
|
||
|
||
> Peter Eisentraut <peter_e@gmx.net> writes:
|
||
> > Remember that a schema is a named representation of ownership, so anything
|
||
> > that can be owned must be in a schema. (Unless you want to invent a
|
||
> > parallel universe for a different kind of ownership, which would be
|
||
> > incredibly confusing.)
|
||
>
|
||
> I don't buy that premise. It's true that SQL92 equates ownership of a
|
||
> schema with ownership of the objects therein, but AFAICS we have no hope
|
||
> of being forward-compatible with existing database setups (wherein there
|
||
> can be multiple tables of different ownership all in a single namespace)
|
||
> if we don't allow varying ownership within a schema. I think we can
|
||
> arrange things so that we are upward compatible with both SQL92 and
|
||
> the old way. Haven't worked out details yet though.
|
||
|
||
Yes we most certianly can! :-)
|
||
|
||
One of the things schemas have to support is essentially a PATH specifier.
|
||
So all we need to do is have all of the schemas created in a new DB have
|
||
path specifiers pulling in all of the other schemas. Thus we can make a
|
||
schema-savy system act as if it has only one namespace.
|
||
|
||
Back when Zembu was paying me to work on this, I envisioned a script or
|
||
tool you'd feed a DB dump, and it would do the schema fixup, including
|
||
adding PATH directives to all schemas, so they all see everything.
|
||
|
||
Since you have to pg_dump when updating, all this adds is running one tool
|
||
during an upgrade. And then existing apps would work. :-)
|
||
|
||
Take care,
|
||
|
||
Bill
|
||
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
|
||
|
||
From pgsql-hackers-owner+M18059=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 15:15:34 2002
|
||
Return-path: <pgsql-hackers-owner+M18059=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0NKFXU06599
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 15:15:34 -0500 (EST)
|
||
Received: (qmail 357 invoked by alias); 23 Jan 2002 20:13:55 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 20:13:55 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0NJvXl94681
|
||
for <pgsql-hackers@postgreSQL.org>; Wed, 23 Jan 2002 14:57:33 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0NJvEf05081;
|
||
Wed, 23 Jan 2002 14:57:14 -0500 (EST)
|
||
To: Bill Studenmund <wrstuden@netbsd.org>
|
||
cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <Pine.NEB.4.33.0201221710360.5119-100000@vespasia.home-net.internetconnect.net>
|
||
References: <Pine.NEB.4.33.0201221710360.5119-100000@vespasia.home-net.internetconnect.net>
|
||
Comments: In-reply-to Bill Studenmund <wrstuden@netbsd.org>
|
||
message dated "Wed, 23 Jan 2002 11:34:23 -0800"
|
||
Date: Wed, 23 Jan 2002 14:57:14 -0500
|
||
Message-ID: <5078.1011815834@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Bill Studenmund <wrstuden@netbsd.org> writes:
|
||
> One of the things schemas have to support is essentially a PATH specifier.
|
||
|
||
Yes, but...
|
||
|
||
> So all we need to do is have all of the schemas created in a new DB have
|
||
> path specifiers pulling in all of the other schemas. Thus we can make a
|
||
> schema-savy system act as if it has only one namespace.
|
||
|
||
When you create a new user, do all those path specifiers for the
|
||
existing users magically update themselves? Seems like maintenance
|
||
would be a pain.
|
||
|
||
Fernando's "any" idea is probably a cleaner way to handle it if we
|
||
wanted to do things like that. But I still think it'll be safer and
|
||
more controllable if we provide a "public" namespace instead; see
|
||
followup discussions.
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 2: you can get off all lists at once with the unregister command
|
||
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
|
||
|
||
From pgsql-hackers-owner+M18061=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 16:04:22 2002
|
||
Return-path: <pgsql-hackers-owner+M18061=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0NL4LU11265
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 16:04:21 -0500 (EST)
|
||
Received: (qmail 21187 invoked by alias); 23 Jan 2002 21:03:47 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 21:03:47 -0000
|
||
Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0NKkVl14074
|
||
for <pgsql-hackers@postgreSQL.org>; Wed, 23 Jan 2002 15:46:32 -0500 (EST)
|
||
(envelope-from wrstuden@netbsd.org)
|
||
Received: (qmail 21707 invoked by uid 1130); 23 Jan 2002 20:46:32 -0000
|
||
Date: Wed, 23 Jan 2002 12:41:48 -0800 (PST)
|
||
From: Bill Studenmund <wrstuden@netbsd.org>
|
||
X-X-Sender: <wrstuden@vespasia.home-net.internetconnect.net>
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <648.1011762477@sss.pgh.pa.us>
|
||
Message-ID: <Pine.NEB.4.33.0201231134290.7050-100000@vespasia.home-net.internetconnect.net>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Wed, 23 Jan 2002, Tom Lane wrote:
|
||
|
||
> Bill Studenmund <wrstuden@netbsd.org> writes:
|
||
> > Why not? What's wrong with either schema.foo.function (==>
|
||
> > function(schema.foo)) or foo.schema.function (==> schema.function(foo))?
|
||
>
|
||
> Neither is wrong in isolation, but how do you tell the difference?
|
||
> More to the point, given input x.y.z, how do you tell which component
|
||
> is what?
|
||
|
||
See below.
|
||
|
||
> > Tables and functions can't have the same names as schemas,
|
||
>
|
||
> News to me. Where is that written on stone tablets? Even if that's
|
||
|
||
I'm still trying to find the quote, but I found it a few months ago. I'm
|
||
looking in SQL99, which is 1100+ pages for section 2. :-)
|
||
|
||
> considered an acceptable limitation from a purely functional point of
|
||
> view, I don't like using it to disambiguate input. The error messages
|
||
> you'll get from incorrect input to an implementation that depends on
|
||
> that to disambiguate cases will not be very helpful.
|
||
|
||
?? Depends on how we do it. As I see it, we have four cases. In the
|
||
x.y.z.p.q, we have:
|
||
|
||
1) No table name, but a function name. It's a function call.
|
||
|
||
2) A table name, but no function name. It's a table reference.
|
||
|
||
3) Both a table name & function name, and the function is first. I think
|
||
this case is an error (I don't think we support function.foo ==
|
||
function(foo))
|
||
|
||
4) Both a table name & function name, and the table is first. This is
|
||
foo.function.
|
||
|
||
Ok, there is a fifth case, no function nor table names, which is an error.
|
||
|
||
> > Actually functions do have to be schema local. It's in the spec (don't
|
||
> > have exactly where with me).
|
||
>
|
||
> (A) I don't believe that; please cite chapter and verse; (B) even if
|
||
|
||
Peter got to that one first.
|
||
|
||
> SQL92 thinks that's okay, we can't do it that way because of
|
||
> backwards-compatibility issues.
|
||
|
||
Why do backwards-compatability issues keep us from doing it?
|
||
|
||
Yes, I understand we have apps now with different users owning things
|
||
(tables, functions) which they all can access, just like they were in one
|
||
unified name space. With real schemas, they are in differen namespaces.
|
||
But as long as the routines, tables, triggers & such in each schema can
|
||
find things in the other schemas as if they were in one namespace, where
|
||
is the problem? We just have the app gain PATH directives to path in all
|
||
the other schemas.
|
||
|
||
The app runs, even though there are different schemas involved. Where is
|
||
the problem?
|
||
|
||
> > My vote would be to make them schema-specific. As Peter pointed out,
|
||
> > schemas are how you own things,
|
||
>
|
||
> Sorry, but this line of argument is trying to assume the very point in
|
||
> dispute.
|
||
|
||
When you started this thread, you said you were thinking about
|
||
"implementing SQL schemas." Are these "SQL schemas" going to follow the
|
||
spec or not? SQL'99 is rather clear that ownership happens at the schema
|
||
level. Peter spent quite a lot of time last October pounding that into my
|
||
head, and after I looked at the spec, I found he was 100% correct.
|
||
|
||
If these schemas are to follow the standards, ownership happens at the
|
||
schema level. If ownership happens elsewhere, whatever we're doing is not
|
||
following the standard. Unfortunatly it's that cut & dried. So why should
|
||
we call them "SQL schemas" if we aren't following the SQL spec?
|
||
|
||
Take care,
|
||
|
||
Bill
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
|
||
|
||
From pgsql-hackers-owner+M18061=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 16:04:22 2002
|
||
Return-path: <pgsql-hackers-owner+M18061=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0NL4LU11264
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 16:04:21 -0500 (EST)
|
||
Received: (qmail 21192 invoked by alias); 23 Jan 2002 21:03:48 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 21:03:48 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0NKvHl19546
|
||
for <pgsql-hackers@postgreSQL.org>; Wed, 23 Jan 2002 15:57:17 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0NKvGf08536;
|
||
Wed, 23 Jan 2002 15:57:16 -0500 (EST)
|
||
To: Bill Studenmund <wrstuden@netbsd.org>
|
||
cc: pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <Pine.NEB.4.33.0201231134290.7050-100000@vespasia.home-net.internetconnect.net>
|
||
References: <Pine.NEB.4.33.0201231134290.7050-100000@vespasia.home-net.internetconnect.net>
|
||
Comments: In-reply-to Bill Studenmund <wrstuden@netbsd.org>
|
||
message dated "Wed, 23 Jan 2002 12:41:48 -0800"
|
||
Date: Wed, 23 Jan 2002 15:57:16 -0500
|
||
Message-ID: <8533.1011819436@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Bill Studenmund <wrstuden@netbsd.org> writes:
|
||
> On Wed, 23 Jan 2002, Tom Lane wrote:
|
||
>> Bill Studenmund <wrstuden@netbsd.org> writes:
|
||
> Why not? What's wrong with either schema.foo.function (==>
|
||
> function(schema.foo)) or foo.schema.function (==> schema.function(foo))?
|
||
>>
|
||
>> Neither is wrong in isolation, but how do you tell the difference?
|
||
>> More to the point, given input x.y.z, how do you tell which component
|
||
>> is what?
|
||
|
||
> ?? Depends on how we do it. As I see it, we have four cases. In the
|
||
> x.y.z.p.q, we have:
|
||
|
||
> 1) No table name, but a function name. It's a function call.
|
||
|
||
> 2) A table name, but no function name. It's a table reference.
|
||
|
||
No, you're missing the point. Which of x,y,z,p,q is the name we
|
||
are going to test to see if it is a table or function? And which
|
||
of these names is a schema name --- if you don't even know that,
|
||
it's hard to argue that checking to see if some name is known is
|
||
a well-defined operation.
|
||
|
||
> When you started this thread, you said you were thinking about
|
||
> "implementing SQL schemas." Are these "SQL schemas" going to follow the
|
||
> spec or not?
|
||
|
||
If you use only the SQL-defined operations, after setting up any
|
||
configuration variables we may invent in the way we will document as
|
||
necessary for SQL-compatible behavior, then you will get SQL-compatible
|
||
behavior. I do not think that precludes having an underlying
|
||
implementation that sees the world differently than SQL does and
|
||
supports non-SQL behaviors too. (For that matter, I'm sure there is
|
||
text somewhere in the spec that points out that the spec intends to
|
||
define user-visible behavior, not implementation.)
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 2: you can get off all lists at once with the unregister command
|
||
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
|
||
|
||
From pgsql-hackers-owner+M18062=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 16:14:05 2002
|
||
Return-path: <pgsql-hackers-owner+M18062=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0NLE4U12279
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 16:14:04 -0500 (EST)
|
||
Received: (qmail 25791 invoked by alias); 23 Jan 2002 21:13:41 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 21:13:41 -0000
|
||
Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0NL3Jl20482
|
||
for <pgsql-hackers@postgreSQL.org>; Wed, 23 Jan 2002 16:03:19 -0500 (EST)
|
||
(envelope-from wrstuden@netbsd.org)
|
||
Received: (qmail 27532 invoked by uid 1130); 23 Jan 2002 21:03:16 -0000
|
||
Date: Wed, 23 Jan 2002 12:58:33 -0800 (PST)
|
||
From: Bill Studenmund <wrstuden@netbsd.org>
|
||
X-X-Sender: <wrstuden@vespasia.home-net.internetconnect.net>
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Peter Eisentraut <peter_e@gmx.net>, <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <5078.1011815834@sss.pgh.pa.us>
|
||
Message-ID: <Pine.NEB.4.33.0201231242120.7050-100000@vespasia.home-net.internetconnect.net>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Wed, 23 Jan 2002, Tom Lane wrote:
|
||
|
||
> Bill Studenmund <wrstuden@netbsd.org> writes:
|
||
> > One of the things schemas have to support is essentially a PATH specifier.
|
||
>
|
||
> Yes, but...
|
||
>
|
||
> > So all we need to do is have all of the schemas created in a new DB have
|
||
> > path specifiers pulling in all of the other schemas. Thus we can make a
|
||
> > schema-savy system act as if it has only one namespace.
|
||
>
|
||
> When you create a new user, do all those path specifiers for the
|
||
> existing users magically update themselves? Seems like maintenance
|
||
> would be a pain.
|
||
|
||
No, they don't. But why should they? Why should they need to?
|
||
|
||
Either we're migrating an existing app, for which adding PATH directives
|
||
with a helper program before restore works, or we're making a new app. If
|
||
you're designing an app for a schema-savy system, you need to think about
|
||
schemas.
|
||
|
||
> Fernando's "any" idea is probably a cleaner way to handle it if we
|
||
> wanted to do things like that. But I still think it'll be safer and
|
||
> more controllable if we provide a "public" namespace instead; see
|
||
> followup discussions.
|
||
|
||
Why? Why is it needed? What would public let you do that PATH and ACLs
|
||
wouldn't?
|
||
|
||
The only reason I can see it's needed is so that people can make new apps
|
||
for a schema-savy PostgreSQL while ignoring the schemas. That strikes me
|
||
as bad. I agree that schemas shouldn't interfeer with things, but to let
|
||
folks just blow them off seems equally bad.
|
||
|
||
Also, it wouldn't be SQL'99 schemas. It can still be done, but it's
|
||
solving a problem that the other SQL'99 databases don't seem to have.
|
||
|
||
Take care,
|
||
|
||
Bill
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 4: Don't 'kill -9' the postmaster
|
||
|
||
From pgsql-hackers-owner+M18065=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 16:33:45 2002
|
||
Return-path: <pgsql-hackers-owner+M18065=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0NLXiU14151
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 16:33:44 -0500 (EST)
|
||
Received: (qmail 32278 invoked by alias); 23 Jan 2002 21:33:41 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 21:33:41 -0000
|
||
Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0NLKGl28778
|
||
for <pgsql-hackers@postgreSQL.org>; Wed, 23 Jan 2002 16:20:16 -0500 (EST)
|
||
(envelope-from wrstuden@netbsd.org)
|
||
Received: (qmail 665 invoked by uid 1130); 23 Jan 2002 21:20:17 -0000
|
||
Date: Wed, 23 Jan 2002 13:15:33 -0800 (PST)
|
||
From: Bill Studenmund <wrstuden@netbsd.org>
|
||
X-X-Sender: <wrstuden@vespasia.home-net.internetconnect.net>
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <8533.1011819436@sss.pgh.pa.us>
|
||
Message-ID: <Pine.NEB.4.33.0201231259150.7050-100000@vespasia.home-net.internetconnect.net>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Wed, 23 Jan 2002, Tom Lane wrote:
|
||
|
||
> Bill Studenmund <wrstuden@netbsd.org> writes:
|
||
> > On Wed, 23 Jan 2002, Tom Lane wrote:
|
||
> >> Bill Studenmund <wrstuden@netbsd.org> writes:
|
||
> > Why not? What's wrong with either schema.foo.function (==>
|
||
> > function(schema.foo)) or foo.schema.function (==> schema.function(foo))?
|
||
> >>
|
||
> >> Neither is wrong in isolation, but how do you tell the difference?
|
||
> >> More to the point, given input x.y.z, how do you tell which component
|
||
> >> is what?
|
||
>
|
||
> > ?? Depends on how we do it. As I see it, we have four cases. In the
|
||
> > x.y.z.p.q, we have:
|
||
>
|
||
> > 1) No table name, but a function name. It's a function call.
|
||
>
|
||
> > 2) A table name, but no function name. It's a table reference.
|
||
>
|
||
> No, you're missing the point. Which of x,y,z,p,q is the name we
|
||
> are going to test to see if it is a table or function? And which
|
||
> of these names is a schema name --- if you don't even know that,
|
||
> it's hard to argue that checking to see if some name is known is
|
||
> a well-defined operation.
|
||
|
||
No, I'm not. :-) You test enough of them to figure out what case you have.
|
||
Yes, it might be a bit of work, but it's doable.
|
||
|
||
Actually, it's not that hard. In foo.funcname, do we support anything
|
||
AFTER the funcname? I don't think so. If there were a parenthesis, then we
|
||
have a function call. If it's an operator or something else, we have
|
||
either a table reference, or a foo.funcname function call. So all we have
|
||
to do is see if p.q (last two elements) is a schema.function, or of q is a
|
||
function pathed into our current schema. If yes, we have foo.function. If
|
||
not, then we have some table reference.
|
||
|
||
> > When you started this thread, you said you were thinking about
|
||
> > "implementing SQL schemas." Are these "SQL schemas" going to follow the
|
||
> > spec or not?
|
||
>
|
||
> If you use only the SQL-defined operations, after setting up any
|
||
> configuration variables we may invent in the way we will document as
|
||
> necessary for SQL-compatible behavior, then you will get SQL-compatible
|
||
> behavior. I do not think that precludes having an underlying
|
||
> implementation that sees the world differently than SQL does and
|
||
> supports non-SQL behaviors too. (For that matter, I'm sure there is
|
||
> text somewhere in the spec that points out that the spec intends to
|
||
> define user-visible behavior, not implementation.)
|
||
|
||
While I agree in principle, that quote is from talking about ownership. I
|
||
don't see how we can gloss over ownership. :-)
|
||
|
||
Also, why support two different behaviors? That means 1) there's code
|
||
bloat since the backend has to support both. 2) Support is harder as major
|
||
DB behaviors will change depending on these settings. 3) I still haven't
|
||
seen anything this variant behavior would do that can't be done with
|
||
schema paths and access control lists, other than it would let people keep
|
||
thinking about things as they do now.
|
||
|
||
That latter reason doesn't strike me as a good one. Yes, it will take some
|
||
getting used to to wrap minds around schemas, but once done, I don't think
|
||
it will be that hard. Yes, the documentation will need work, and the
|
||
tutorial will need changing (And Bruce will need to release a new edition
|
||
of his book :-) , but once that's done, I don't think working with real
|
||
schemas will be that hard. So why not just do things right from the
|
||
begining?
|
||
|
||
Take care,
|
||
|
||
Bill
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
|
||
|
||
From pgsql-hackers-owner+M18064=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 16:23:32 2002
|
||
Return-path: <pgsql-hackers-owner+M18064=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0NLNVU13386
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 16:23:31 -0500 (EST)
|
||
Received: (qmail 29442 invoked by alias); 23 Jan 2002 21:23:26 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 21:23:26 -0000
|
||
Received: from stubee.d2hosting.net (d2hosting.net [66.70.41.160])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0NLGVl28360
|
||
for <pgsql-hackers@postgresql.org>; Wed, 23 Jan 2002 16:16:31 -0500 (EST)
|
||
(envelope-from tswan-lst@ics.olemiss.edu)
|
||
Received: from ics.olemiss.edu (adsl-81-102-77.jan.bellsouth.net [65.81.102.77])
|
||
by stubee.d2hosting.net (8.11.6/linuxconf) with ESMTP id g0NLGLT00962;
|
||
Wed, 23 Jan 2002 15:16:22 -0600
|
||
Message-ID: <3C4F2824.90709@ics.olemiss.edu>
|
||
Date: Wed, 23 Jan 2002 15:16:20 -0600
|
||
From: Thomas Swan <tswan-lst@ics.olemiss.edu>
|
||
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7+) Gecko/20020123
|
||
X-Accept-Language: en-us
|
||
MIME-Version: 1.0
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Stephan Szabo <sszabo@megazone23.bigpanda.com>,
|
||
Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org,
|
||
Fernando Nasser <fnasser@redhat.com>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
References: <20020123083152.W18169-100000@megazone23.bigpanda.com> <3159.1011804418@sss.pgh.pa.us>
|
||
Content-Type: text/html; charset=us-ascii
|
||
Content-Transfer-Encoding: 7bit
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||
<html>
|
||
<head>
|
||
<title></title>
|
||
</head>
|
||
<body>
|
||
Tom Lane wrote:<br>
|
||
<blockquote type="cite" cite="mid:3159.1011804418@sss.pgh.pa.us">
|
||
<pre wrap="">Stephan Szabo <a class="moz-txt-link-rfc2396E" href="mailto:sszabo@megazone23.bigpanda.com"><sszabo@megazone23.bigpanda.com></a> writes:<br></pre>
|
||
<blockquote type="cite">
|
||
<pre wrap="">Wouldn't it make sense to prefer operators/functions earlier in the search<br>path for resolving ambiguity. So if you had plus(int4, int4) in my<br>schema and plus(int8, int8) in system, and they'd otherwise cause an<br>ambiguity failure for the query, use the plus(int4, int4) on mine. It<br>seems not too far from having the search path shadow later exact matches.<br></pre>
|
||
</blockquote>
|
||
<pre wrap=""><!----><br>Given the complexity of the resolution rules (cf.<br><a class="moz-txt-link-freetext" href="http://developer.postgresql.org/docs/postgres/typeconv.html">http://developer.postgresql.org/docs/postgres/typeconv.html</a>),<br>it's not clear that we can determine exactly which "later" entry ought<br>to be blamed for causing a resolution failure. I'd be interested to<br>hear Lockhart's opinion on this --- but my gut feeling is we don't<br>want to go there. The resolution rules are already complicated enough,<br>and I think layering an additional mechanism like that onto them might<br>make the behavior totally unpredictable.<br><br>Another problem is that this would probably cause earlier namespace<br>entries to be over-preferred. For example, suppose that the system<br>namespace has plus(int4,int4) and plus(int8,int8) and you choose to<br>define plus(int4,int8) locally. I believe you'd suddenly find yours<br>being used for *any* cross-datatype addit
|
||
ion, including cases that<br>had nothing obvious to do with either int4 or int8 ...<br></pre>
|
||
</blockquote>
|
||
This is a good example. The other option is to use name, arg1, arg2...
|
||
as a hunt path for function call resolution. This would depend on when datatype
|
||
promotion is occuring (i.e. int4 to int8, int8 to int4, etc... )<br>
|
||
<br>
|
||
Then you could just be really hard and say that only exact and trivial conversion
|
||
matches in user space will be used . <br>
|
||
<br>
|
||
There is no easy answer for this, but whatever rules are initiated need to
|
||
be something that someone can step through to solve w/o a machine.<br>
|
||
<br>
|
||
I do think you will ultimately need a search utility that provides 'which'
|
||
functionality. (Given my namespace, which function in what namespace is
|
||
going to be called.)<br>
|
||
<blockquote type="cite" cite="mid:3159.1011804418@sss.pgh.pa.us">
|
||
<pre wrap=""><br><br> regards, tom lane<br><br>---------------------------(end of broadcast)---------------------------<br>TIP 1: subscribe and unsubscribe commands go to <a class="moz-txt-link-abbreviated" href="mailto:majordomo@postgresql.org">majordomo@postgresql.org</a><br></pre>
|
||
</blockquote>
|
||
<br>
|
||
<br>
|
||
</body>
|
||
</html>
|
||
|
||
|
||
From pgsql-hackers-owner+M18066=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 16:45:11 2002
|
||
Return-path: <pgsql-hackers-owner+M18066=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0NLjAU15010
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 16:45:11 -0500 (EST)
|
||
Received: (qmail 39170 invoked by alias); 23 Jan 2002 21:43:48 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 21:43:48 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0NLQpl30489
|
||
for <pgsql-hackers@postgreSQL.org>; Wed, 23 Jan 2002 16:26:51 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0NLQXf08750;
|
||
Wed, 23 Jan 2002 16:26:33 -0500 (EST)
|
||
To: Bill Studenmund <wrstuden@netbsd.org>
|
||
cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <Pine.NEB.4.33.0201231242120.7050-100000@vespasia.home-net.internetconnect.net>
|
||
References: <Pine.NEB.4.33.0201231242120.7050-100000@vespasia.home-net.internetconnect.net>
|
||
Comments: In-reply-to Bill Studenmund <wrstuden@netbsd.org>
|
||
message dated "Wed, 23 Jan 2002 12:58:33 -0800"
|
||
Date: Wed, 23 Jan 2002 16:26:33 -0500
|
||
Message-ID: <8747.1011821193@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Bill Studenmund <wrstuden@netbsd.org> writes:
|
||
> Either we're migrating an existing app, for which adding PATH directives
|
||
> with a helper program before restore works, or we're making a new app.
|
||
|
||
Sorry, I don't accept that either-or proposition. People will expect to
|
||
be able to continue to use 7.3 as they have used Postgres in the past.
|
||
Among other things that will mean being able to add new users to an
|
||
existing installation. If we say "you can't do much of anything in 7.3
|
||
until you upgrade all your applications to schema-awareness", then we're
|
||
going to have lots of unhappy users.
|
||
|
||
>> Fernando's "any" idea is probably a cleaner way to handle it if we
|
||
>> wanted to do things like that. But I still think it'll be safer and
|
||
>> more controllable if we provide a "public" namespace instead; see
|
||
>> followup discussions.
|
||
|
||
> Why? Why is it needed? What would public let you do that PATH and ACLs
|
||
> wouldn't?
|
||
|
||
Public gives you a place to put the ACL determining what people can do
|
||
with publicly-visible names. See, eg, comments from Joe Conway.
|
||
Without a specific public namespace to put ACLs on, a dbadmin has very
|
||
little control over interuser interactions. Please note that the
|
||
facility we are talking about offering here is not available in existing
|
||
Postgres nor in SQL92, but that doesn't make it evil or unreasonable.
|
||
|
||
Basically my point here is that the SQL spec is not the be-all and
|
||
end-all of database development. (Have you read C. J. Date's commentary
|
||
on it, for example?) We have a proven useful concept of object ownership
|
||
in existing Postgres, and I see no need to remove that facility in
|
||
pursuit of slavish adherence to a specification. If it were a project
|
||
goal to rip out everything in Postgres that is not mentioned in the
|
||
SQL spec, we could have a much smaller distribution ... with lots fewer
|
||
users.
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 4: Don't 'kill -9' the postmaster
|
||
|
||
From pgsql-hackers-owner+M18067=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 17:04:34 2002
|
||
Return-path: <pgsql-hackers-owner+M18067=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0NM4XU16392
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 17:04:33 -0500 (EST)
|
||
Received: (qmail 47125 invoked by alias); 23 Jan 2002 22:04:32 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 22:04:32 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0NLk1l42602
|
||
for <pgsql-hackers@postgreSQL.org>; Wed, 23 Jan 2002 16:46:01 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0NLk1f08845;
|
||
Wed, 23 Jan 2002 16:46:01 -0500 (EST)
|
||
To: Bill Studenmund <wrstuden@netbsd.org>
|
||
cc: pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <Pine.NEB.4.33.0201231259150.7050-100000@vespasia.home-net.internetconnect.net>
|
||
References: <Pine.NEB.4.33.0201231259150.7050-100000@vespasia.home-net.internetconnect.net>
|
||
Comments: In-reply-to Bill Studenmund <wrstuden@netbsd.org>
|
||
message dated "Wed, 23 Jan 2002 13:15:33 -0800"
|
||
Date: Wed, 23 Jan 2002 16:46:01 -0500
|
||
Message-ID: <8842.1011822361@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Bill Studenmund <wrstuden@netbsd.org> writes:
|
||
>> No, you're missing the point. Which of x,y,z,p,q is the name we
|
||
>> are going to test to see if it is a table or function?
|
||
|
||
> No, I'm not. :-) You test enough of them to figure out what case you have.
|
||
|
||
There could be multiple valid interpretations. When you can't even
|
||
figure out where to start, it's too squishy for me. Code complexity
|
||
isn't really the issue here, it's whether a user can understand what's
|
||
going on.
|
||
|
||
> Actually, it's not that hard. In foo.funcname, do we support anything
|
||
> AFTER the funcname? I don't think so. If there were a parenthesis, then we
|
||
> have a function call. If it's an operator or something else, we have
|
||
> either a table reference, or a foo.funcname function call. So all we have
|
||
> to do is see if p.q (last two elements) is a schema.function, or of q is a
|
||
> function pathed into our current schema. If yes, we have foo.function. If
|
||
> not, then we have some table reference.
|
||
|
||
Now wait a sec. What you started out with was the claim
|
||
|
||
> Why not? What's wrong with either schema.foo.function (==>
|
||
> function(schema.foo)) or foo.schema.function (==> schema.function(foo))?
|
||
|
||
The issue was not figuring out whether the last component was a function
|
||
name or not, it was to determine what the other components were, and in
|
||
particular whether the function name should be presumed to be qualified
|
||
(by the next-to-last component taken as a schema name) or unqualified.
|
||
That in turns changes your assumptions about which of the components
|
||
further left are table names, schema names, or catalog names.
|
||
|
||
> ... I don't think working with real
|
||
> schemas will be that hard. So why not just do things right from the
|
||
> begining?
|
||
|
||
If I thought that SQL's model of ownership == namespace was "right",
|
||
then we probably wouldn't be having this argument. I think the spec
|
||
pretty much sucks in this particular department, and I don't see why
|
||
we should restrict our implementation to support only the spec's
|
||
braindead world view. Especially not when it makes the implementation
|
||
harder, not easier, because we end up needing to add in weird frammishes
|
||
to have some semblance of backwards-compatibility too.
|
||
|
||
Please give me some good reasons (not "the spec says so") why it's
|
||
a good idea to treat ownership of a namespace as equivalent to ownership
|
||
of the objects in it, and why decoupling the concepts at the
|
||
implementation level isn't a reasonable thing to do.
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 2: you can get off all lists at once with the unregister command
|
||
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
|
||
|
||
From pgsql-hackers-owner+M18070=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 17:43:52 2002
|
||
Return-path: <pgsql-hackers-owner+M18070=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0NMhpU18760
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 17:43:51 -0500 (EST)
|
||
Received: (qmail 53592 invoked by alias); 23 Jan 2002 22:43:08 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 22:43:08 -0000
|
||
Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0NMP4l51662
|
||
for <pgsql-hackers@postgreSQL.org>; Wed, 23 Jan 2002 17:25:04 -0500 (EST)
|
||
(envelope-from wrstuden@netbsd.org)
|
||
Received: (qmail 9718 invoked by uid 1130); 23 Jan 2002 22:25:06 -0000
|
||
Date: Wed, 23 Jan 2002 14:20:22 -0800 (PST)
|
||
From: Bill Studenmund <wrstuden@netbsd.org>
|
||
X-X-Sender: <wrstuden@vespasia.home-net.internetconnect.net>
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <8842.1011822361@sss.pgh.pa.us>
|
||
Message-ID: <Pine.NEB.4.33.0201231344110.7050-100000@vespasia.home-net.internetconnect.net>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Wed, 23 Jan 2002, Tom Lane wrote:
|
||
|
||
> Bill Studenmund <wrstuden@netbsd.org> writes:
|
||
> >> No, you're missing the point. Which of x,y,z,p,q is the name we
|
||
> >> are going to test to see if it is a table or function?
|
||
>
|
||
> > No, I'm not. :-) You test enough of them to figure out what case you have.
|
||
>
|
||
> There could be multiple valid interpretations. When you can't even
|
||
> figure out where to start, it's too squishy for me. Code complexity
|
||
> isn't really the issue here, it's whether a user can understand what's
|
||
> going on.
|
||
>
|
||
> > Actually, it's not that hard. In foo.funcname, do we support anything
|
||
> > AFTER the funcname? I don't think so. If there were a parenthesis, then we
|
||
> > have a function call. If it's an operator or something else, we have
|
||
> > either a table reference, or a foo.funcname function call. So all we have
|
||
> > to do is see if p.q (last two elements) is a schema.function, or of q is a
|
||
> > function pathed into our current schema. If yes, we have foo.function. If
|
||
> > not, then we have some table reference.
|
||
>
|
||
> Now wait a sec. What you started out with was the claim
|
||
>
|
||
> > Why not? What's wrong with either schema.foo.function (==>
|
||
> > function(schema.foo)) or foo.schema.function (==> schema.function(foo))?
|
||
>
|
||
> The issue was not figuring out whether the last component was a function
|
||
> name or not, it was to determine what the other components were, and in
|
||
> particular whether the function name should be presumed to be qualified
|
||
> (by the next-to-last component taken as a schema name) or unqualified.
|
||
> That in turns changes your assumptions about which of the components
|
||
> further left are table names, schema names, or catalog names.
|
||
|
||
Then you choose. Choose a search order, and document it. If you are going
|
||
to go back into a corner full of so much ambiguity, then document your way
|
||
out.
|
||
|
||
You can make it easier restricting say catalogs and schemas to have
|
||
different names, or schemas, tables, and functions can't have the same
|
||
name. For this, I'd suggest following Oracle's example. I don't think you
|
||
can go too wrong using Oracle's behavior to break ties & ambiguities.
|
||
|
||
> > ... I don't think working with real
|
||
> > schemas will be that hard. So why not just do things right from the
|
||
> > begining?
|
||
>
|
||
> If I thought that SQL's model of ownership == namespace was "right",
|
||
> then we probably wouldn't be having this argument. I think the spec
|
||
> pretty much sucks in this particular department, and I don't see why
|
||
> we should restrict our implementation to support only the spec's
|
||
> braindead world view. Especially not when it makes the implementation
|
||
> harder, not easier, because we end up needing to add in weird frammishes
|
||
> to have some semblance of backwards-compatibility too.
|
||
|
||
?? What weird fammishes from ownership?
|
||
|
||
It actually makes things (slightly) simpler. All of the owner fields
|
||
disapear from most system tables, because the owner is implied by the
|
||
containing schema.
|
||
|
||
Also, what is braindead about the spec? Yes, it's not what I would choose,
|
||
and it's different from what PG does now. But it's just that, different.
|
||
Given all of the ACL abilities (if the superuser wants user X to be able
|
||
to create objects in table Y of schema Z, s/he makes it so), why does it
|
||
matter who owns the object?
|
||
|
||
> Please give me some good reasons (not "the spec says so") why it's
|
||
> a good idea to treat ownership of a namespace as equivalent to ownership
|
||
> of the objects in it, and why decoupling the concepts at the
|
||
> implementation level isn't a reasonable thing to do.
|
||
|
||
Can you really give a good reason other than, "I don't like it?"
|
||
|
||
Absent the existance of specs, it's a matter of choice. Having all of the
|
||
ownership happen at the schema level or at the individual item level, it's
|
||
six of one, half-dozen of the other.
|
||
|
||
But there is a spec. A spec that, as far as I can tell, all other
|
||
schema-claming DBs follow. So why shouldn't we follow it? Yes, you don't
|
||
like it. But is this really supposed to be about personal desires, or
|
||
about the resulting DB?
|
||
|
||
Take care,
|
||
|
||
Bill
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 3: if posting/reading through Usenet, please send an appropriate
|
||
subscribe-nomail command to majordomo@postgresql.org so that your
|
||
message can get through to the mailing list cleanly
|
||
|
||
From pgsql-hackers-owner+M18072=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 18:14:00 2002
|
||
Return-path: <pgsql-hackers-owner+M18072=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0NNDxU20711
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 18:14:00 -0500 (EST)
|
||
Received: (qmail 61874 invoked by alias); 23 Jan 2002 23:13:20 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 23:13:20 -0000
|
||
Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0NMitl56697
|
||
for <pgsql-hackers@postgreSQL.org>; Wed, 23 Jan 2002 17:44:55 -0500 (EST)
|
||
(envelope-from wrstuden@netbsd.org)
|
||
Received: (qmail 10914 invoked by uid 1130); 23 Jan 2002 22:44:56 -0000
|
||
Date: Wed, 23 Jan 2002 14:40:12 -0800 (PST)
|
||
From: Bill Studenmund <wrstuden@netbsd.org>
|
||
X-X-Sender: <wrstuden@vespasia.home-net.internetconnect.net>
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Peter Eisentraut <peter_e@gmx.net>, <pgsql-hackers@postgresql.org>,
|
||
Fernando Nasser <fnasser@redhat.com>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <2600.1011799885@sss.pgh.pa.us>
|
||
Message-ID: <Pine.NEB.4.33.0201231435300.7050-100000@vespasia.home-net.internetconnect.net>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Wed, 23 Jan 2002, Tom Lane wrote:
|
||
|
||
> Peter Eisentraut <peter_e@gmx.net> writes:
|
||
> > OK, I can accept that. But then I want to get back at my original point,
|
||
> > namely that all database objects (except users and groups) should be in
|
||
> > schemas. This is also cleaner, simpler, and more flexible. There is
|
||
> > clearly demand for schema-local functions. So I think that designing this
|
||
> > system from the premise that a schema-qualified operator call will look
|
||
> > strange is the wrong end to start at.
|
||
>
|
||
> Okay, a fair point --- or you could have used my own argument against
|
||
> me: there's nothing wrong with designing a general mechanism and then
|
||
> choosing not to expose all of the functionality. So let's assume that
|
||
> functions and operators live in namespaces, and that we have some kind
|
||
> of search path across multiple namespaces for use when an unqualified
|
||
> name is given.
|
||
>
|
||
> Now, how is that going to play with resolution of ambiguous calls?
|
||
>
|
||
> The most reasonable semantics I can think of are to collect all the
|
||
> potential matches (matching op/func name) across all the searchable
|
||
> namespaces, discarding only those that have exactly the same signature
|
||
> as one in a prior namespace. Thus, eg, plus(int4,int4) in an earlier
|
||
> namespace would hide plus(int4,int4) in a later namespace in the search
|
||
> path, but it wouldn't hide plus(int8,int8). After we've collected all
|
||
> the visible alternatives, do resolution based on argument types the same
|
||
> way as we do now.
|
||
>
|
||
> The only alternative semantics that seem defensible at all are to stop
|
||
> at the first namespace that contains any matching-by-name op or func,
|
||
> and do resolution using only the candidates available in that namespace.
|
||
> That strikes me as not a good idea; for example, a user who defines a
|
||
> "+" operator in his own schema for his own datatype would be quite
|
||
> unhappy to find it masking all the "+" operators in the system schema.
|
||
|
||
There is a third behavior which is almost the first one. And it's the one
|
||
I use for function matching in the package diffs I made oh so long ago.
|
||
:-)
|
||
|
||
You look in the first namespace for all candidates. If one matches, you
|
||
use it. If two or more match, you throw the error we throw now. If none
|
||
match, you move on to the next namespace and repeat the search there.
|
||
|
||
It's what the code does now. It's not that hard. It's just essentially
|
||
turning part of the function lookup into a for loop over the namespaces.
|
||
:-)
|
||
|
||
It's easier than gathering everything as you only gather one namespace's
|
||
worth of matches at once.
|
||
|
||
Take care,
|
||
|
||
Bill
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 5: Have you checked our extensive FAQ?
|
||
|
||
http://www.postgresql.org/users-lounge/docs/faq.html
|
||
|
||
From pgsql-hackers-owner+M18071=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 18:14:06 2002
|
||
Return-path: <pgsql-hackers-owner+M18071=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0NNE5U20779
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 18:14:06 -0500 (EST)
|
||
Received: (qmail 62072 invoked by alias); 23 Jan 2002 23:13:28 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 23:13:28 -0000
|
||
Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0NMsEl57927
|
||
for <pgsql-hackers@postgresql.org>; Wed, 23 Jan 2002 17:54:14 -0500 (EST)
|
||
(envelope-from wrstuden@netbsd.org)
|
||
Received: (qmail 13221 invoked by uid 1130); 23 Jan 2002 22:54:16 -0000
|
||
Date: Wed, 23 Jan 2002 14:49:32 -0800 (PST)
|
||
From: Bill Studenmund <wrstuden@netbsd.org>
|
||
X-X-Sender: <wrstuden@vespasia.home-net.internetconnect.net>
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Zeugswetter Andreas SB SD <ZeugswetterA@spardat.at>,
|
||
Fernando Nasser <fnasser@redhat.com>, Peter Eisentraut <peter_e@gmx.net>,
|
||
<pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <2677.1011800674@sss.pgh.pa.us>
|
||
Message-ID: <Pine.NEB.4.33.0201231443440.7050-100000@vespasia.home-net.internetconnect.net>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Wed, 23 Jan 2002, Tom Lane wrote:
|
||
|
||
> "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
|
||
> > When configured for historical behavior would need to:
|
||
> > 1. have search path: temp, any, system
|
||
> > 2. guard against duplicate table names across all schemas (except temp schema)
|
||
>
|
||
> This would be a *whole* lot simpler if we forgot the notion of "any"
|
||
> and made the search order look like
|
||
>
|
||
> (temp, private, public, system)
|
||
>
|
||
> where the public namespace is world-writable but the private per-user
|
||
> ones are (typically at least) not.
|
||
>
|
||
> It occurs to me that we can get both backward-compatible and SQL92
|
||
> semantics with this same search path; the only thing that needs to
|
||
> be different in the two cases is whether the default place to create
|
||
> objects is your private schema or the public one. If you don't ever
|
||
> use your private schema then it doesn't matter if it's on the search
|
||
> path or not. I would still prefer that the search path be a settable
|
||
> option, since a paranoid person might well wish to not have public in
|
||
> his path at all ... but the default could be as-above.
|
||
|
||
s/public/DEFAULT/ and add a way (createdb option) to make the default ACL
|
||
on DEFAULT such that anyone can create things and we are in agreement.
|
||
|
||
One of the parts of the schema system I'd envisioned (and tried to make)
|
||
was that there would be an IMPLIMENTATION_SCHEMA which owned all
|
||
built-ins, and a DEFAULT schema which was owned by the superuser. Making
|
||
the default schema path for a schema
|
||
IMPLIMENTATION_SCHEMA:<SCHEMA_NAME>:DEFAULT is fine.
|
||
|
||
Making the default schema for creation settable to DEFAULT would be fine,
|
||
and I think would remove objection. :-)
|
||
|
||
Take care,
|
||
|
||
Bill
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 5: Have you checked our extensive FAQ?
|
||
|
||
http://www.postgresql.org/users-lounge/docs/faq.html
|
||
|
||
From pgsql-hackers-owner+M18073=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 18:14:19 2002
|
||
Return-path: <pgsql-hackers-owner+M18073=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0NNEIU20817
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 18:14:18 -0500 (EST)
|
||
Received: (qmail 61956 invoked by alias); 23 Jan 2002 23:13:23 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 23:13:23 -0000
|
||
Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0NN0Cl58411
|
||
for <pgsql-hackers@postgreSQL.org>; Wed, 23 Jan 2002 18:00:12 -0500 (EST)
|
||
(envelope-from wrstuden@netbsd.org)
|
||
Received: (qmail 14480 invoked by uid 1130); 23 Jan 2002 23:00:14 -0000
|
||
Date: Wed, 23 Jan 2002 14:55:29 -0800 (PST)
|
||
From: Bill Studenmund <wrstuden@netbsd.org>
|
||
X-X-Sender: <wrstuden@vespasia.home-net.internetconnect.net>
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Peter Eisentraut <peter_e@gmx.net>, <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <8747.1011821193@sss.pgh.pa.us>
|
||
Message-ID: <Pine.NEB.4.33.0201231420310.7050-100000@vespasia.home-net.internetconnect.net>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Wed, 23 Jan 2002, Tom Lane wrote:
|
||
|
||
> Bill Studenmund <wrstuden@netbsd.org> writes:
|
||
> > Either we're migrating an existing app, for which adding PATH directives
|
||
> > with a helper program before restore works, or we're making a new app.
|
||
>
|
||
> Sorry, I don't accept that either-or proposition. People will expect to
|
||
> be able to continue to use 7.3 as they have used Postgres in the past.
|
||
> Among other things that will mean being able to add new users to an
|
||
> existing installation. If we say "you can't do much of anything in 7.3
|
||
> until you upgrade all your applications to schema-awareness", then we're
|
||
> going to have lots of unhappy users.
|
||
|
||
"upgrad[ing] .. to schema-awareness" is adding the PATHs to the schema
|
||
creates. You then have a unified namespace (to the apps perspective). The
|
||
migration tool I mentioned should be able to do this (and will need to be
|
||
present).
|
||
|
||
As PostgreSQL changes, people are going to have to learn to deal with new
|
||
features. I really don't think that dealing with schemas is going to be
|
||
that hard. Also, at Zembu, all of the apps we looked at had maybe two or
|
||
three schemas. These are big apps. If they can live with just a few
|
||
schemas, why do we need so many that maintainance is a pain?
|
||
|
||
Also, what is this new user going to do *IN THE EXISTING APP*? Either the
|
||
user is going to change existing tables, for which adding the user to the
|
||
ACLs (or better yet to a group) will work, or the new user is going to own
|
||
new tables. If the new user is owning new tables, then you have to change
|
||
the app to refer to them. If the upgrade to 7.3 included a, "quick
|
||
tutorial about the new schema support," the author should be able to adapt
|
||
easily.
|
||
|
||
> >> Fernando's "any" idea is probably a cleaner way to handle it if we
|
||
> >> wanted to do things like that. But I still think it'll be safer and
|
||
> >> more controllable if we provide a "public" namespace instead; see
|
||
> >> followup discussions.
|
||
>
|
||
> > Why? Why is it needed? What would public let you do that PATH and ACLs
|
||
> > wouldn't?
|
||
>
|
||
> Public gives you a place to put the ACL determining what people can do
|
||
> with publicly-visible names. See, eg, comments from Joe Conway.
|
||
> Without a specific public namespace to put ACLs on, a dbadmin has very
|
||
> little control over interuser interactions. Please note that the
|
||
> facility we are talking about offering here is not available in existing
|
||
> Postgres nor in SQL92, but that doesn't make it evil or unreasonable.
|
||
|
||
I think the existance of a DEFAULT schema (which is a real schema, not a
|
||
special namespace) would also aleviate the above concerns.
|
||
|
||
> Basically my point here is that the SQL spec is not the be-all and
|
||
> end-all of database development. (Have you read C. J. Date's commentary
|
||
> on it, for example?) We have a proven useful concept of object ownership
|
||
> in existing Postgres, and I see no need to remove that facility in
|
||
> pursuit of slavish adherence to a specification. If it were a project
|
||
> goal to rip out everything in Postgres that is not mentioned in the
|
||
> SQL spec, we could have a much smaller distribution ... with lots fewer
|
||
> users.
|
||
|
||
I haven't read the comentary, do you have a URL?
|
||
|
||
I agree that we should not limit ourselves to SQL'99. But doing more than
|
||
SQL'99 is different from wanting to support SQL schemas while using a
|
||
different ownership model, when one of the main things of SQL schemas as I
|
||
understand it is the ownership model.
|
||
|
||
Take care,
|
||
|
||
Bill
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
|
||
|
||
From pgsql-hackers-owner+M18075=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 18:33:16 2002
|
||
Return-path: <pgsql-hackers-owner+M18075=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0NNXGU21830
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 18:33:16 -0500 (EST)
|
||
Received: (qmail 68962 invoked by alias); 23 Jan 2002 23:33:14 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 23 Jan 2002 23:33:14 -0000
|
||
Received: from megazone.bigpanda.com (megazone.bigpanda.com [63.150.15.178])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0NNUFl68439
|
||
for <pgsql-hackers@postgreSQL.org>; Wed, 23 Jan 2002 18:30:15 -0500 (EST)
|
||
(envelope-from sszabo@megazone23.bigpanda.com)
|
||
Received: by megazone.bigpanda.com (Postfix, from userid 1001)
|
||
id 4D769D5F7; Wed, 23 Jan 2002 15:30:07 -0800 (PST)
|
||
Received: from localhost (localhost [127.0.0.1])
|
||
by megazone.bigpanda.com (Postfix) with ESMTP
|
||
id 412425BF5; Wed, 23 Jan 2002 15:30:07 -0800 (PST)
|
||
Date: Wed, 23 Jan 2002 15:30:07 -0800 (PST)
|
||
From: Stephan Szabo <sszabo@megazone23.bigpanda.com>
|
||
To: Bill Studenmund <wrstuden@netbsd.org>
|
||
cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
|
||
<pgsql-hackers@postgresql.org>, Fernando Nasser <fnasser@redhat.com>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <Pine.NEB.4.33.0201231435300.7050-100000@vespasia.home-net.internetconnect.net>
|
||
Message-ID: <20020123152711.I22382-100000@megazone23.bigpanda.com>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Wed, 23 Jan 2002, Bill Studenmund wrote:
|
||
|
||
> On Wed, 23 Jan 2002, Tom Lane wrote:
|
||
>
|
||
> There is a third behavior which is almost the first one. And it's the one
|
||
> I use for function matching in the package diffs I made oh so long ago.
|
||
> :-)
|
||
>
|
||
> You look in the first namespace for all candidates. If one matches, you
|
||
> use it. If two or more match, you throw the error we throw now. If none
|
||
> match, you move on to the next namespace and repeat the search there.
|
||
|
||
That's even more strongly towards earlier namespaces than my suggestion.
|
||
How do you define match? If you allow coercions, then the
|
||
plus(int8, int8) in my schema would be prefered over better (possibly
|
||
exact) matches in the system schema which may not be what you want.
|
||
|
||
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 5: Have you checked our extensive FAQ?
|
||
|
||
http://www.postgresql.org/users-lounge/docs/faq.html
|
||
|
||
From pgsql-hackers-owner+M18078=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 19:04:16 2002
|
||
Return-path: <pgsql-hackers-owner+M18078=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0O04GU23131
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 19:04:16 -0500 (EST)
|
||
Received: (qmail 74730 invoked by alias); 24 Jan 2002 00:03:43 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 24 Jan 2002 00:03:43 -0000
|
||
Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0NNqbl73179
|
||
for <pgsql-hackers@postgreSQL.org>; Wed, 23 Jan 2002 18:52:37 -0500 (EST)
|
||
(envelope-from wrstuden@netbsd.org)
|
||
Received: (qmail 20343 invoked by uid 1130); 23 Jan 2002 23:52:39 -0000
|
||
Date: Wed, 23 Jan 2002 15:47:55 -0800 (PST)
|
||
From: Bill Studenmund <wrstuden@netbsd.org>
|
||
X-X-Sender: <wrstuden@vespasia.home-net.internetconnect.net>
|
||
To: Stephan Szabo <sszabo@megazone23.bigpanda.com>
|
||
cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
|
||
<pgsql-hackers@postgresql.org>, Fernando Nasser <fnasser@redhat.com>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <20020123152711.I22382-100000@megazone23.bigpanda.com>
|
||
Message-ID: <Pine.NEB.4.33.0201231535590.7050-100000@vespasia.home-net.internetconnect.net>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Wed, 23 Jan 2002, Stephan Szabo wrote:
|
||
|
||
> On Wed, 23 Jan 2002, Bill Studenmund wrote:
|
||
>
|
||
> > On Wed, 23 Jan 2002, Tom Lane wrote:
|
||
> >
|
||
> > There is a third behavior which is almost the first one. And it's the one
|
||
> > I use for function matching in the package diffs I made oh so long ago.
|
||
> > :-)
|
||
> >
|
||
> > You look in the first namespace for all candidates. If one matches, you
|
||
> > use it. If two or more match, you throw the error we throw now. If none
|
||
> > match, you move on to the next namespace and repeat the search there.
|
||
>
|
||
> That's even more strongly towards earlier namespaces than my suggestion.
|
||
> How do you define match? If you allow coercions, then the
|
||
> plus(int8, int8) in my schema would be prefered over better (possibly
|
||
> exact) matches in the system schema which may not be what you want.
|
||
|
||
True. But:
|
||
|
||
1) How often are you going to make routines with names that duplicate
|
||
those in the system schema, when you don't want them to be used?
|
||
|
||
2) you can always explicitly refer to the system schema, so you can get
|
||
the routine you want if it's not the one you'll get by coercion.
|
||
|
||
3) We tested other (commercial) databases, and they have this behavior, so
|
||
it seems a reasonable thing to do.
|
||
|
||
4) It's simple and easy to understand.
|
||
|
||
Take care,
|
||
|
||
Bill
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 6: Have you searched our list archives?
|
||
|
||
http://archives.postgresql.org
|
||
|
||
From pgsql-hackers-owner+M18079=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 19:13:55 2002
|
||
Return-path: <pgsql-hackers-owner+M18079=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0O0DsU23615
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 19:13:55 -0500 (EST)
|
||
Received: (qmail 79143 invoked by alias); 24 Jan 2002 00:13:37 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 24 Jan 2002 00:13:37 -0000
|
||
Received: from megazone.bigpanda.com (megazone.bigpanda.com [63.150.15.178])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0O074l78013
|
||
for <pgsql-hackers@postgreSQL.org>; Wed, 23 Jan 2002 19:07:04 -0500 (EST)
|
||
(envelope-from sszabo@megazone23.bigpanda.com)
|
||
Received: by megazone.bigpanda.com (Postfix, from userid 1001)
|
||
id 7D1CFD5F7; Wed, 23 Jan 2002 16:07:07 -0800 (PST)
|
||
Received: from localhost (localhost [127.0.0.1])
|
||
by megazone.bigpanda.com (Postfix) with ESMTP
|
||
id 6EC505BF5; Wed, 23 Jan 2002 16:07:07 -0800 (PST)
|
||
Date: Wed, 23 Jan 2002 16:07:07 -0800 (PST)
|
||
From: Stephan Szabo <sszabo@megazone23.bigpanda.com>
|
||
To: Bill Studenmund <wrstuden@netbsd.org>
|
||
cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
|
||
<pgsql-hackers@postgresql.org>, Fernando Nasser <fnasser@redhat.com>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <Pine.NEB.4.33.0201231535590.7050-100000@vespasia.home-net.internetconnect.net>
|
||
Message-ID: <20020123155603.Y22713-100000@megazone23.bigpanda.com>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Wed, 23 Jan 2002, Bill Studenmund wrote:
|
||
|
||
> On Wed, 23 Jan 2002, Stephan Szabo wrote:
|
||
>
|
||
> > On Wed, 23 Jan 2002, Bill Studenmund wrote:
|
||
> >
|
||
> > > On Wed, 23 Jan 2002, Tom Lane wrote:
|
||
> > >
|
||
> > > There is a third behavior which is almost the first one. And it's the one
|
||
> > > I use for function matching in the package diffs I made oh so long ago.
|
||
> > > :-)
|
||
> > >
|
||
> > > You look in the first namespace for all candidates. If one matches, you
|
||
> > > use it. If two or more match, you throw the error we throw now. If none
|
||
> > > match, you move on to the next namespace and repeat the search there.
|
||
> >
|
||
> > That's even more strongly towards earlier namespaces than my suggestion.
|
||
> > How do you define match? If you allow coercions, then the
|
||
> > plus(int8, int8) in my schema would be prefered over better (possibly
|
||
> > exact) matches in the system schema which may not be what you want.
|
||
>
|
||
> True. But:
|
||
>
|
||
> 1) How often are you going to make routines with names that duplicate
|
||
> those in the system schema, when you don't want them to be used?
|
||
|
||
Sure, you want them used when the arguments match, but what about when
|
||
they don't exactly?
|
||
If the system schema has foo(integer) and in my schema I make a new type
|
||
and then make a type(integer) and foo(type), when I call foo(1), do I
|
||
really mean do a coersion to my type and call foo(type)?
|
||
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
|
||
|
||
From pgsql-hackers-owner+M18082=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 19:33:21 2002
|
||
Return-path: <pgsql-hackers-owner+M18082=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0O0XKU24428
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 19:33:21 -0500 (EST)
|
||
Received: (qmail 85643 invoked by alias); 24 Jan 2002 00:33:19 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 24 Jan 2002 00:33:19 -0000
|
||
Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0O0N0l83366
|
||
for <pgsql-hackers@postgreSQL.org>; Wed, 23 Jan 2002 19:23:00 -0500 (EST)
|
||
(envelope-from wrstuden@netbsd.org)
|
||
Received: (qmail 24329 invoked by uid 1130); 24 Jan 2002 00:23:02 -0000
|
||
Date: Wed, 23 Jan 2002 16:18:18 -0800 (PST)
|
||
From: Bill Studenmund <wrstuden@netbsd.org>
|
||
X-X-Sender: <wrstuden@vespasia.home-net.internetconnect.net>
|
||
To: Stephan Szabo <sszabo@megazone23.bigpanda.com>
|
||
cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
|
||
<pgsql-hackers@postgresql.org>, Fernando Nasser <fnasser@redhat.com>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <20020123155603.Y22713-100000@megazone23.bigpanda.com>
|
||
Message-ID: <Pine.NEB.4.33.0201231606090.7050-100000@vespasia.home-net.internetconnect.net>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Wed, 23 Jan 2002, Stephan Szabo wrote:
|
||
|
||
> On Wed, 23 Jan 2002, Bill Studenmund wrote:
|
||
>
|
||
> > True. But:
|
||
> >
|
||
> > 1) How often are you going to make routines with names that duplicate
|
||
> > those in the system schema, when you don't want them to be used?
|
||
>
|
||
> Sure, you want them used when the arguments match, but what about when
|
||
> they don't exactly?
|
||
> If the system schema has foo(integer) and in my schema I make a new type
|
||
> and then make a type(integer) and foo(type), when I call foo(1), do I
|
||
> really mean do a coersion to my type and call foo(type)?
|
||
|
||
Yes, you did. The documentation said that that would happen, so since you
|
||
made the call ambiguous, you wanted the coercion to happen. Or at least
|
||
you weren't concerned that it might.
|
||
|
||
Take care,
|
||
|
||
Bill
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 5: Have you checked our extensive FAQ?
|
||
|
||
http://www.postgresql.org/users-lounge/docs/faq.html
|
||
|
||
From pgsql-hackers-owner+M18083=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 19:43:17 2002
|
||
Return-path: <pgsql-hackers-owner+M18083=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0O0hGU24835
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 19:43:16 -0500 (EST)
|
||
Received: (qmail 88309 invoked by alias); 24 Jan 2002 00:43:14 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 24 Jan 2002 00:43:14 -0000
|
||
Received: from megazone.bigpanda.com (megazone.bigpanda.com [63.150.15.178])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0O0YUl87134
|
||
for <pgsql-hackers@postgreSQL.org>; Wed, 23 Jan 2002 19:34:30 -0500 (EST)
|
||
(envelope-from sszabo@megazone23.bigpanda.com)
|
||
Received: by megazone.bigpanda.com (Postfix, from userid 1001)
|
||
id 11552D5F8; Wed, 23 Jan 2002 16:34:33 -0800 (PST)
|
||
Received: from localhost (localhost [127.0.0.1])
|
||
by megazone.bigpanda.com (Postfix) with ESMTP
|
||
id 050095BF5; Wed, 23 Jan 2002 16:34:33 -0800 (PST)
|
||
Date: Wed, 23 Jan 2002 16:34:32 -0800 (PST)
|
||
From: Stephan Szabo <sszabo@megazone23.bigpanda.com>
|
||
To: Bill Studenmund <wrstuden@netbsd.org>
|
||
cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
|
||
<pgsql-hackers@postgresql.org>, Fernando Nasser <fnasser@redhat.com>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <Pine.NEB.4.33.0201231606090.7050-100000@vespasia.home-net.internetconnect.net>
|
||
Message-ID: <20020123162426.K22713-100000@megazone23.bigpanda.com>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Wed, 23 Jan 2002, Bill Studenmund wrote:
|
||
|
||
> On Wed, 23 Jan 2002, Stephan Szabo wrote:
|
||
>
|
||
> > On Wed, 23 Jan 2002, Bill Studenmund wrote:
|
||
> >
|
||
> > > True. But:
|
||
> > >
|
||
> > > 1) How often are you going to make routines with names that duplicate
|
||
> > > those in the system schema, when you don't want them to be used?
|
||
> >
|
||
> > Sure, you want them used when the arguments match, but what about when
|
||
> > they don't exactly?
|
||
> > If the system schema has foo(integer) and in my schema I make a new type
|
||
> > and then make a type(integer) and foo(type), when I call foo(1), do I
|
||
> > really mean do a coersion to my type and call foo(type)?
|
||
>
|
||
> Yes, you did. The documentation said that that would happen, so since you
|
||
|
||
It doesn't currently say anything of the sort. If we made the above
|
||
behavior the standard, it would, but that's sort of circular. ;) Unless
|
||
I'm misreading the page Tom sent me to earlier, it seems to say it
|
||
prefers matches with exact types over coercions which would no longer be
|
||
true.
|
||
|
||
> made the call ambiguous, you wanted the coercion to happen. Or at least
|
||
> you weren't concerned that it might.
|
||
|
||
I still disagree. If I make a complex number type in my schema,
|
||
I don't really intend integer+integer to convert to complex and give me a
|
||
complex answer even if I want to be able to cast integers into complex.
|
||
AFAIK there's no way to specify that I want to make the function
|
||
complex(integer) such that I can do CAST(1 as complex) but not as an
|
||
implicit cast.
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 3: if posting/reading through Usenet, please send an appropriate
|
||
subscribe-nomail command to majordomo@postgresql.org so that your
|
||
message can get through to the mailing list cleanly
|
||
|
||
From pgsql-hackers-owner+M18084=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 20:06:02 2002
|
||
Return-path: <pgsql-hackers-owner+M18084=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0O161U25898
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 20:06:01 -0500 (EST)
|
||
Received: (qmail 91014 invoked by alias); 24 Jan 2002 01:05:59 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 24 Jan 2002 01:05:59 -0000
|
||
Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0O0qTl89749
|
||
for <pgsql-hackers@postgreSQL.org>; Wed, 23 Jan 2002 19:52:29 -0500 (EST)
|
||
(envelope-from wrstuden@netbsd.org)
|
||
Received: (qmail 1144 invoked by uid 1130); 24 Jan 2002 00:52:32 -0000
|
||
Date: Wed, 23 Jan 2002 16:47:48 -0800 (PST)
|
||
From: Bill Studenmund <wrstuden@netbsd.org>
|
||
X-X-Sender: <wrstuden@vespasia.home-net.internetconnect.net>
|
||
To: Stephan Szabo <sszabo@megazone23.bigpanda.com>
|
||
cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
|
||
<pgsql-hackers@postgresql.org>, Fernando Nasser <fnasser@redhat.com>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <20020123162426.K22713-100000@megazone23.bigpanda.com>
|
||
Message-ID: <Pine.NEB.4.33.0201231636150.7050-100000@vespasia.home-net.internetconnect.net>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Wed, 23 Jan 2002, Stephan Szabo wrote:
|
||
|
||
> On Wed, 23 Jan 2002, Bill Studenmund wrote:
|
||
>
|
||
> > On Wed, 23 Jan 2002, Stephan Szabo wrote:
|
||
> >
|
||
> > Yes, you did. The documentation said that that would happen, so since you
|
||
>
|
||
> It doesn't currently say anything of the sort. If we made the above
|
||
> behavior the standard, it would, but that's sort of circular. ;) Unless
|
||
> I'm misreading the page Tom sent me to earlier, it seems to say it
|
||
> prefers matches with exact types over coercions which would no longer be
|
||
> true.
|
||
|
||
The documentation says nothing about schemas at all now, so obviously it
|
||
has to change. :-)
|
||
|
||
> > made the call ambiguous, you wanted the coercion to happen. Or at least
|
||
> > you weren't concerned that it might.
|
||
>
|
||
> I still disagree. If I make a complex number type in my schema,
|
||
> I don't really intend integer+integer to convert to complex and give me a
|
||
> complex answer even if I want to be able to cast integers into complex.
|
||
> AFAIK there's no way to specify that I want to make the function
|
||
> complex(integer) such that I can do CAST(1 as complex) but not as an
|
||
> implicit cast.
|
||
|
||
Note: I've been talking about functions, and you're talking about
|
||
operators. While operators are syntactic sugar for functions, one big
|
||
difference is that you can't specify explicit schemas for operators (nor
|
||
do I think you should be able to). I think exact matches for operators
|
||
anywhere in the path would be better than local coercable ones.
|
||
|
||
Does SQL'99 say anything about this?
|
||
|
||
Take care,
|
||
|
||
Bill
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 6: Have you searched our list archives?
|
||
|
||
http://archives.postgresql.org
|
||
|
||
From pgsql-hackers-owner+M18086=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 20:25:47 2002
|
||
Return-path: <pgsql-hackers-owner+M18086=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0O1PkU26965
|
||
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 20:25:47 -0500 (EST)
|
||
Received: (qmail 94892 invoked by alias); 24 Jan 2002 01:25:45 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 24 Jan 2002 01:25:45 -0000
|
||
Received: from megazone.bigpanda.com (megazone.bigpanda.com [63.150.15.178])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0O1MNl94162
|
||
for <pgsql-hackers@postgreSQL.org>; Wed, 23 Jan 2002 20:22:24 -0500 (EST)
|
||
(envelope-from sszabo@megazone23.bigpanda.com)
|
||
Received: by megazone.bigpanda.com (Postfix, from userid 1001)
|
||
id 5B37BD5F7; Wed, 23 Jan 2002 17:22:26 -0800 (PST)
|
||
Received: from localhost (localhost [127.0.0.1])
|
||
by megazone.bigpanda.com (Postfix) with ESMTP
|
||
id 50EA45BF5; Wed, 23 Jan 2002 17:22:26 -0800 (PST)
|
||
Date: Wed, 23 Jan 2002 17:22:26 -0800 (PST)
|
||
From: Stephan Szabo <sszabo@megazone23.bigpanda.com>
|
||
To: Bill Studenmund <wrstuden@netbsd.org>
|
||
cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
|
||
<pgsql-hackers@postgresql.org>, Fernando Nasser <fnasser@redhat.com>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <Pine.NEB.4.33.0201231636150.7050-100000@vespasia.home-net.internetconnect.net>
|
||
Message-ID: <20020123165321.K23306-100000@megazone23.bigpanda.com>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Wed, 23 Jan 2002, Bill Studenmund wrote:
|
||
|
||
What I was getting at was that Tom's behavior (or even mine) is more
|
||
similar to the currently described behavior than the suggested one.
|
||
|
||
> > > made the call ambiguous, you wanted the coercion to happen. Or at least
|
||
> > > you weren't concerned that it might.
|
||
> >
|
||
> > I still disagree. If I make a complex number type in my schema,
|
||
> > I don't really intend integer+integer to convert to complex and give me a
|
||
> > complex answer even if I want to be able to cast integers into complex.
|
||
> > AFAIK there's no way to specify that I want to make the function
|
||
> > complex(integer) such that I can do CAST(1 as complex) but not as an
|
||
> > implicit cast.
|
||
>
|
||
> Note: I've been talking about functions, and you're talking about
|
||
> operators. While operators are syntactic sugar for functions, one big
|
||
> difference is that you can't specify explicit schemas for operators (nor
|
||
> do I think you should be able to). I think exact matches for operators
|
||
> anywhere in the path would be better than local coercable ones.
|
||
|
||
I'd say the same thing for a random math function as well. For example
|
||
if there was a square(int) that returned $1*$1 and I made a square for my
|
||
complex type, I'd still expect that square(5) is an integer rather than a
|
||
complex using the square(complex). For example, I'd expect square(5) to
|
||
be a valid length argument to substr.
|
||
|
||
> Does SQL'99 say anything about this?
|
||
That I don't know about (don't have a draft around to look at). I'm not
|
||
sure that it'd have these problems though unless it's got the same sort of
|
||
coercion system.
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 6: Have you searched our list archives?
|
||
|
||
http://archives.postgresql.org
|
||
|
||
From pgsql-hackers-owner+M18095=candle.pha.pa.us=pgman@postgresql.org Thu Jan 24 00:43:04 2002
|
||
Return-path: <pgsql-hackers-owner+M18095=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0O5h4U15469
|
||
for <pgman@candle.pha.pa.us>; Thu, 24 Jan 2002 00:43:04 -0500 (EST)
|
||
Received: (qmail 28221 invoked by alias); 24 Jan 2002 05:43:00 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 24 Jan 2002 05:43:00 -0000
|
||
Received: from student.gvsu.edu ([148.61.7.124])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0O5QCl26727
|
||
for <pgsql-hackers@postgreSQL.org>; Thu, 24 Jan 2002 00:26:13 -0500 (EST)
|
||
(envelope-from peter_e@gmx.net)
|
||
Received: from [148.61.250.90] [148.61.250.90] by student.gvsu.edu
|
||
with Novonyx SMTP Server $Revision: 1.3 $; Thu, 24 Jan 2002 00:26:11 -0500 (EDT)
|
||
Date: Thu, 24 Jan 2002 00:28:16 -0500 (EST)
|
||
From: Peter Eisentraut <peter_e@gmx.net>
|
||
X-Sender: <peter@peter.localdomain>
|
||
To: Bill Studenmund <wrstuden@netbsd.org>
|
||
cc: Stephan Szabo <sszabo@megazone23.bigpanda.com>,
|
||
Tom Lane <tgl@sss.pgh.pa.us>,
|
||
PostgreSQL Development <pgsql-hackers@postgresql.org>,
|
||
Fernando Nasser <fnasser@redhat.com>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <Pine.NEB.4.33.0201231636150.7050-100000@vespasia.home-net.internetconnect.net>
|
||
Message-ID: <Pine.LNX.4.30.0201240003120.686-100000@peter.localdomain>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Bill Studenmund writes:
|
||
|
||
> Does SQL'99 say anything about this?
|
||
|
||
Yes, though, as usual, you have to twist your brain a little to understand
|
||
it. My understanding is that for a function call of the form "foo(a, b)"
|
||
it goes like this:
|
||
|
||
1. Find all functions named "foo" in the current database. This is the
|
||
set of "possibly candidate routines".
|
||
|
||
2. Drop all routines that you do not have EXECUTE privilege for. This is
|
||
the set of "executable routines".
|
||
|
||
3. Drop all routines that do not have compatible parameter lists. This is
|
||
the set of "invocable routines".
|
||
|
||
4. Drop all routines whose schema is not in the path. This is the set of
|
||
"candidate routines".
|
||
|
||
5. If you have more than one routine left, eliminate some routines
|
||
according to type precedence rules. (We do some form of this, SQL99
|
||
specifies something different.) This yields the set of "candidate subject
|
||
routines".
|
||
|
||
6. Choose the routine whose schema is earliest in the path as the "subject
|
||
routine".
|
||
|
||
Execute the subject routine. Phew!
|
||
|
||
|
||
This doesn't look glaringly wrong to me, so maybe you want to consider it.
|
||
Please note step 2.
|
||
|
||
--
|
||
Peter Eisentraut peter_e@gmx.net
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 6: Have you searched our list archives?
|
||
|
||
http://archives.postgresql.org
|
||
|
||
From pgsql-hackers-owner+M18127=candle.pha.pa.us=pgman@postgresql.org Thu Jan 24 14:53:53 2002
|
||
Return-path: <pgsql-hackers-owner+M18127=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0OJrqU16554
|
||
for <pgman@candle.pha.pa.us>; Thu, 24 Jan 2002 14:53:52 -0500 (EST)
|
||
Received: (qmail 59340 invoked by alias); 24 Jan 2002 19:53:33 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 24 Jan 2002 19:53:33 -0000
|
||
Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0OJprl58616
|
||
for <pgsql-hackers@postgreSQL.org>; Thu, 24 Jan 2002 14:51:53 -0500 (EST)
|
||
(envelope-from wrstuden@netbsd.org)
|
||
Received: (qmail 22083 invoked by uid 1130); 24 Jan 2002 19:51:54 -0000
|
||
Date: Thu, 24 Jan 2002 11:47:07 -0800 (PST)
|
||
From: Bill Studenmund <wrstuden@netbsd.org>
|
||
X-X-Sender: <wrstuden@vespasia.home-net.internetconnect.net>
|
||
To: Stephan Szabo <sszabo@megazone23.bigpanda.com>
|
||
cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
|
||
<pgsql-hackers@postgresql.org>, Fernando Nasser <fnasser@redhat.com>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <20020123165321.K23306-100000@megazone23.bigpanda.com>
|
||
Message-ID: <Pine.NEB.4.33.0201241138130.9384-100000@vespasia.home-net.internetconnect.net>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Wed, 23 Jan 2002, Stephan Szabo wrote:
|
||
|
||
> On Wed, 23 Jan 2002, Bill Studenmund wrote:
|
||
>
|
||
> What I was getting at was that Tom's behavior (or even mine) is more
|
||
> similar to the currently described behavior than the suggested one.
|
||
|
||
I understand. As part of developing the package changes, though, I found
|
||
that Oracle used the method I described for finding routines in packages.
|
||
|
||
>From Peter's description, it sounds like Oracle's not following the spec.
|
||
|
||
> I'd say the same thing for a random math function as well. For example
|
||
> if there was a square(int) that returned $1*$1 and I made a square for my
|
||
> complex type, I'd still expect that square(5) is an integer rather than a
|
||
> complex using the square(complex). For example, I'd expect square(5) to
|
||
> be a valid length argument to substr.
|
||
|
||
Yeah, that makes sense.
|
||
|
||
> > Does SQL'99 say anything about this?
|
||
> That I don't know about (don't have a draft around to look at). I'm not
|
||
|
||
Do you want pdfs?
|
||
|
||
> sure that it'd have these problems though unless it's got the same sort of
|
||
> coercion system.
|
||
|
||
I don't think it has the same sort of coercion, but it has some, I'd
|
||
expect (as all of the DBs I know of have some sort of coercion :-)
|
||
|
||
Take care,
|
||
|
||
Bill
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
|
||
|
||
From pgsql-hackers-owner+M18128=candle.pha.pa.us=pgman@postgresql.org Thu Jan 24 15:04:41 2002
|
||
Return-path: <pgsql-hackers-owner+M18128=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0OK4eU18207
|
||
for <pgman@candle.pha.pa.us>; Thu, 24 Jan 2002 15:04:40 -0500 (EST)
|
||
Received: (qmail 65543 invoked by alias); 24 Jan 2002 20:03:53 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 24 Jan 2002 20:03:53 -0000
|
||
Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0OJsul61073
|
||
for <pgsql-hackers@postgreSQL.org>; Thu, 24 Jan 2002 14:54:57 -0500 (EST)
|
||
(envelope-from wrstuden@netbsd.org)
|
||
Received: (qmail 23026 invoked by uid 1130); 24 Jan 2002 19:54:57 -0000
|
||
Date: Thu, 24 Jan 2002 11:50:12 -0800 (PST)
|
||
From: Bill Studenmund <wrstuden@netbsd.org>
|
||
X-X-Sender: <wrstuden@vespasia.home-net.internetconnect.net>
|
||
To: Peter Eisentraut <peter_e@gmx.net>
|
||
cc: Stephan Szabo <sszabo@megazone23.bigpanda.com>,
|
||
Tom Lane <tgl@sss.pgh.pa.us>,
|
||
PostgreSQL Development <pgsql-hackers@postgresql.org>,
|
||
Fernando Nasser <fnasser@redhat.com>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <Pine.LNX.4.30.0201240003120.686-100000@peter.localdomain>
|
||
Message-ID: <Pine.NEB.4.33.0201241147131.9384-100000@vespasia.home-net.internetconnect.net>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Thu, 24 Jan 2002, Peter Eisentraut wrote:
|
||
|
||
> Bill Studenmund writes:
|
||
>
|
||
> > Does SQL'99 say anything about this?
|
||
>
|
||
> Yes, though, as usual, you have to twist your brain a little to understand
|
||
> it.
|
||
|
||
Indeed. I find the spec makes the most sense after you understand it. ;-)
|
||
|
||
> My understanding is that for a function call of the form "foo(a, b)"
|
||
> it goes like this:
|
||
>
|
||
> 1. Find all functions named "foo" in the current database. This is the
|
||
> set of "possibly candidate routines".
|
||
>
|
||
> 2. Drop all routines that you do not have EXECUTE privilege for. This is
|
||
> the set of "executable routines".
|
||
>
|
||
> 3. Drop all routines that do not have compatible parameter lists. This is
|
||
> the set of "invocable routines".
|
||
>
|
||
> 4. Drop all routines whose schema is not in the path. This is the set of
|
||
> "candidate routines".
|
||
>
|
||
> 5. If you have more than one routine left, eliminate some routines
|
||
> according to type precedence rules. (We do some form of this, SQL99
|
||
> specifies something different.) This yields the set of "candidate subject
|
||
> routines".
|
||
>
|
||
> 6. Choose the routine whose schema is earliest in the path as the "subject
|
||
> routine".
|
||
>
|
||
> Execute the subject routine. Phew!
|
||
|
||
Wow. Thanks for diging this out.
|
||
|
||
> This doesn't look glaringly wrong to me, so maybe you want to consider it.
|
||
> Please note step 2.
|
||
|
||
It looks fine, and is probably what we should do. Well, I'd do things in a
|
||
different order (look only in in-path schemas first for instance), but
|
||
that's just trying to optimize the query. :-)
|
||
|
||
How different are the type coercion rules?
|
||
|
||
Take care,
|
||
|
||
Bill
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 6: Have you searched our list archives?
|
||
|
||
http://archives.postgresql.org
|
||
|
||
From pgsql-hackers-owner+M18156=candle.pha.pa.us=pgman@postgresql.org Thu Jan 24 22:45:56 2002
|
||
Return-path: <pgsql-hackers-owner+M18156=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0P3jte02265
|
||
for <pgman@candle.pha.pa.us>; Thu, 24 Jan 2002 22:45:55 -0500 (EST)
|
||
Received: (qmail 95096 invoked by alias); 25 Jan 2002 03:45:50 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 25 Jan 2002 03:45:50 -0000
|
||
Received: from candle.pha.pa.us (216-55-132-35.dsl.san-diego.abac.net [216.55.132.35])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0P3NWl91448
|
||
for <pgsql-hackers@postgresql.org>; Thu, 24 Jan 2002 22:23:33 -0500 (EST)
|
||
(envelope-from pgman@candle.pha.pa.us)
|
||
Received: (from pgman@localhost)
|
||
by candle.pha.pa.us (8.11.6/8.10.1) id g0P3NMY22893;
|
||
Thu, 24 Jan 2002 22:23:22 -0500 (EST)
|
||
From: Bruce Momjian <pgman@candle.pha.pa.us>
|
||
Message-ID: <200201250323.g0P3NMY22893@candle.pha.pa.us>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <2677.1011800674@sss.pgh.pa.us>
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Date: Thu, 24 Jan 2002 22:23:22 -0500 (EST)
|
||
cc: Zeugswetter Andreas SB SD <ZeugswetterA@spardat.at>,
|
||
Fernando Nasser <fnasser@redhat.com>, Peter Eisentraut <peter_e@gmx.net>,
|
||
pgsql-hackers@postgresql.org
|
||
X-Mailer: ELM [version 2.4ME+ PL96 (25)]
|
||
MIME-Version: 1.0
|
||
Content-Transfer-Encoding: 7bit
|
||
Content-Type: text/plain; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Tom Lane wrote:
|
||
> "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
|
||
> > When configured for historical behavior would need to:
|
||
> > 1. have search path: temp, any, system
|
||
> > 2. guard against duplicate table names across all schemas (except temp schema)
|
||
>
|
||
> This would be a *whole* lot simpler if we forgot the notion of "any"
|
||
> and made the search order look like
|
||
>
|
||
> (temp, private, public, system)
|
||
>
|
||
> where the public namespace is world-writable but the private per-user
|
||
> ones are (typically at least) not.
|
||
|
||
[ I am just reading this schema thread now.]
|
||
|
||
The above private/public idea seems like a much better than 'any'. That
|
||
'any' thing had me quite confused and the idea thought you would have
|
||
duplicates that would only be found at runtime seems destined to random
|
||
falures.
|
||
|
||
I assume 'private' above means search in my personal schema/namespace.
|
||
|
||
--
|
||
Bruce Momjian | http://candle.pha.pa.us
|
||
pgman@candle.pha.pa.us | (610) 853-3000
|
||
+ If your life is a hard drive, | 830 Blythe Avenue
|
||
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 6: Have you searched our list archives?
|
||
|
||
http://archives.postgresql.org
|
||
|
||
From pgsql-hackers-owner+M18157=candle.pha.pa.us=pgman@postgresql.org Thu Jan 24 22:45:56 2002
|
||
Return-path: <pgsql-hackers-owner+M18157=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0P3jte02266
|
||
for <pgman@candle.pha.pa.us>; Thu, 24 Jan 2002 22:45:55 -0500 (EST)
|
||
Received: (qmail 95098 invoked by alias); 25 Jan 2002 03:45:50 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 25 Jan 2002 03:45:50 -0000
|
||
Received: from candle.pha.pa.us (216-55-132-35.dsl.san-diego.abac.net [216.55.132.35])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0P3Qql91635
|
||
for <pgsql-hackers@postgresql.org>; Thu, 24 Jan 2002 22:26:52 -0500 (EST)
|
||
(envelope-from pgman@candle.pha.pa.us)
|
||
Received: (from pgman@localhost)
|
||
by candle.pha.pa.us (8.11.6/8.10.1) id g0P3Qhw23061;
|
||
Thu, 24 Jan 2002 22:26:43 -0500 (EST)
|
||
From: Bruce Momjian <pgman@candle.pha.pa.us>
|
||
Message-ID: <200201250326.g0P3Qhw23061@candle.pha.pa.us>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <2677.1011800674@sss.pgh.pa.us>
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Date: Thu, 24 Jan 2002 22:26:43 -0500 (EST)
|
||
cc: Zeugswetter Andreas SB SD <ZeugswetterA@spardat.at>,
|
||
Fernando Nasser <fnasser@redhat.com>, Peter Eisentraut <peter_e@gmx.net>,
|
||
pgsql-hackers@postgresql.org
|
||
X-Mailer: ELM [version 2.4ME+ PL96 (25)]
|
||
MIME-Version: 1.0
|
||
Content-Transfer-Encoding: 7bit
|
||
Content-Type: text/plain; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
> > Or are you thinking about a per session behavior ?
|
||
> > I would rather envision a per database behavior.
|
||
> > Maybe the easy way out would be a "default creation schema" property for
|
||
> > each user, that would default to the username. If you want everything in one
|
||
> > schema simply alter the users.
|
||
>
|
||
> I hadn't really gotten to the point of thinking about exactly what and
|
||
> where the control knobs should be. I suspect you are right that we will
|
||
> want the default behavior to be selectable on a per-user or per-database
|
||
> basis, which seems to eliminate the option of using GUC (at least in its
|
||
> current form). We could easily add a field to pg_shadow or pg_database
|
||
> respectively to determine the default behavior. It'd be nice though if
|
||
> the behavior could be changed after connection by a SET statement, which
|
||
> would be lots easier if the setting were GUC-controlled. Peter, you see
|
||
> any way to resolve that?
|
||
|
||
I think we could set the database default at db creation time, then
|
||
allow SET to modify that default per session; seems flexible enough.
|
||
It is basically a GUC value who's default is stored in pg_database
|
||
rather than postgresql.conf. You could use postgresql.conf to set the
|
||
default schema type at db creation time.
|
||
|
||
--
|
||
Bruce Momjian | http://candle.pha.pa.us
|
||
pgman@candle.pha.pa.us | (610) 853-3000
|
||
+ If your life is a hard drive, | 830 Blythe Avenue
|
||
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 6: Have you searched our list archives?
|
||
|
||
http://archives.postgresql.org
|
||
|
||
From pgsql-hackers-owner+M18158=candle.pha.pa.us=pgman@postgresql.org Thu Jan 24 23:03:48 2002
|
||
Return-path: <pgsql-hackers-owner+M18158=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0P43le13410
|
||
for <pgman@candle.pha.pa.us>; Thu, 24 Jan 2002 23:03:47 -0500 (EST)
|
||
Received: (qmail 97941 invoked by alias); 25 Jan 2002 04:03:42 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 25 Jan 2002 04:03:42 -0000
|
||
Received: from student.gvsu.edu ([148.61.7.124])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0P3wjl97273
|
||
for <pgsql-hackers@postgresql.org>; Thu, 24 Jan 2002 22:58:46 -0500 (EST)
|
||
(envelope-from peter_e@gmx.net)
|
||
Received: from [148.61.250.128] [148.61.250.128] by student.gvsu.edu
|
||
with Novonyx SMTP Server $Revision: 1.3 $; Thu, 24 Jan 2002 22:58:51 -0500 (EDT)
|
||
Date: Thu, 24 Jan 2002 23:00:57 -0500 (EST)
|
||
From: Peter Eisentraut <peter_e@gmx.net>
|
||
X-Sender: <peter@peter.localdomain>
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Zeugswetter Andreas SB SD <ZeugswetterA@spardat.at>,
|
||
Fernando Nasser <fnasser@redhat.com>, <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <2677.1011800674@sss.pgh.pa.us>
|
||
Message-ID: <Pine.LNX.4.30.0201242259280.686-100000@peter.localdomain>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: ORr
|
||
|
||
Tom Lane writes:
|
||
|
||
> It'd be nice though if
|
||
> the behavior could be changed after connection by a SET statement, which
|
||
> would be lots easier if the setting were GUC-controlled. Peter, you see
|
||
> any way to resolve that?
|
||
|
||
We had a text[] field to pg_shadow and/or pg_database containing
|
||
name=value assignments which are executed just before the session starts.
|
||
Doesn't look terribly difficult, and it's something I've always wanted to
|
||
do anyway.
|
||
|
||
--
|
||
Peter Eisentraut peter_e@gmx.net
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 6: Have you searched our list archives?
|
||
|
||
http://archives.postgresql.org
|
||
|
||
From pgsql-hackers-owner+M18160=candle.pha.pa.us=pgman@postgresql.org Thu Jan 24 23:45:22 2002
|
||
Return-path: <pgsql-hackers-owner+M18160=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0P4jLe11106
|
||
for <pgman@candle.pha.pa.us>; Thu, 24 Jan 2002 23:45:21 -0500 (EST)
|
||
Received: (qmail 3520 invoked by alias); 25 Jan 2002 04:43:35 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 25 Jan 2002 04:43:35 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0P4OAl00294
|
||
for <pgsql-hackers@postgresql.org>; Thu, 24 Jan 2002 23:24:11 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0P4Nef23267;
|
||
Thu, 24 Jan 2002 23:23:40 -0500 (EST)
|
||
To: Peter Eisentraut <peter_e@gmx.net>
|
||
cc: Zeugswetter Andreas SB SD <ZeugswetterA@spardat.at>,
|
||
Fernando Nasser <fnasser@redhat.com>, pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <Pine.LNX.4.30.0201242259280.686-100000@peter.localdomain>
|
||
References: <Pine.LNX.4.30.0201242259280.686-100000@peter.localdomain>
|
||
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
|
||
message dated "Thu, 24 Jan 2002 23:00:57 -0500"
|
||
Date: Thu, 24 Jan 2002 23:23:39 -0500
|
||
Message-ID: <23264.1011932619@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Peter Eisentraut <peter_e@gmx.net> writes:
|
||
> We [add] a text[] field to pg_shadow and/or pg_database containing
|
||
> name=value assignments which are executed just before the session starts.
|
||
> Doesn't look terribly difficult, and it's something I've always wanted to
|
||
> do anyway.
|
||
|
||
Seems like a fine idea, with many uses besides this one.
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 3: if posting/reading through Usenet, please send an appropriate
|
||
subscribe-nomail command to majordomo@postgresql.org so that your
|
||
message can get through to the mailing list cleanly
|
||
|
||
From pgsql-hackers-owner+M18159=candle.pha.pa.us=pgman@postgresql.org Thu Jan 24 23:33:32 2002
|
||
Return-path: <pgsql-hackers-owner+M18159=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0P4XVe10435
|
||
for <pgman@candle.pha.pa.us>; Thu, 24 Jan 2002 23:33:31 -0500 (EST)
|
||
Received: (qmail 1069 invoked by alias); 25 Jan 2002 04:33:26 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 25 Jan 2002 04:33:26 -0000
|
||
Received: from linuxworld.com.au (www.linuxworld.com.au [203.34.46.50])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0P4Pal00372
|
||
for <pgsql-hackers@postgresql.org>; Thu, 24 Jan 2002 23:25:36 -0500 (EST)
|
||
(envelope-from swm@linuxworld.com.au)
|
||
Received: from localhost (swm@localhost)
|
||
by linuxworld.com.au (8.11.4/8.11.4) with ESMTP id g0P4P5Z12976;
|
||
Fri, 25 Jan 2002 15:25:05 +1100
|
||
Date: Fri, 25 Jan 2002 15:25:05 +1100 (EST)
|
||
From: Gavin Sherry <swm@linuxworld.com.au>
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Bill Studenmund <wrstuden@netbsd.org>, pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <8533.1011819436@sss.pgh.pa.us>
|
||
Message-ID: <Pine.LNX.4.21.0201251517350.12632-100000@linuxworld.com.au>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Wed, 23 Jan 2002, Tom Lane wrote:
|
||
|
||
> If you use only the SQL-defined operations, after setting up any
|
||
> configuration variables we may invent in the way we will document as
|
||
> necessary for SQL-compatible behavior, then you will get SQL-compatible
|
||
> behavior. I do not think that precludes having an underlying
|
||
> implementation that sees the world differently than SQL does and
|
||
> supports non-SQL behaviors too. (For that matter, I'm sure there is
|
||
> text somewhere in the spec that points out that the spec intends to
|
||
> define user-visible behavior, not implementation.)
|
||
|
||
This makes a lot of sense and suggests the possibility of 'schema enabled'
|
||
databases. That is, a switch 'bool withschemas' (which defaults to
|
||
false) could be added to pg_database. If true, the parser and ownership
|
||
model reflects that of SQL'99 and/or the Postgres schema model. If false,
|
||
the existing 'schema' model is assumed.
|
||
|
||
This should allow existing users to migrate their data and applications to
|
||
7.3 without having to modify either.
|
||
|
||
Its not an ideal solution but backward compatibility is generally results
|
||
in compromise ;).
|
||
|
||
Gavin
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 4: Don't 'kill -9' the postmaster
|
||
|
||
From pgsql-hackers-owner+M18164=candle.pha.pa.us=pgman@postgresql.org Thu Jan 24 23:45:36 2002
|
||
Return-path: <pgsql-hackers-owner+M18164=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0P4jae11220
|
||
for <pgman@candle.pha.pa.us>; Thu, 24 Jan 2002 23:45:36 -0500 (EST)
|
||
Received: (qmail 4119 invoked by alias); 25 Jan 2002 04:43:57 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 25 Jan 2002 04:43:57 -0000
|
||
Received: from candle.pha.pa.us (216-55-132-35.dsl.san-diego.abac.net [216.55.132.35])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0P4Y0l01902
|
||
for <pgsql-hackers@postgresql.org>; Thu, 24 Jan 2002 23:34:00 -0500 (EST)
|
||
(envelope-from pgman@candle.pha.pa.us)
|
||
Received: (from pgman@localhost)
|
||
by candle.pha.pa.us (8.11.6/8.10.1) id g0P4XqD10470;
|
||
Thu, 24 Jan 2002 23:33:52 -0500 (EST)
|
||
From: Bruce Momjian <pgman@candle.pha.pa.us>
|
||
Message-ID: <200201250433.g0P4XqD10470@candle.pha.pa.us>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <Pine.LNX.4.30.0201242259280.686-100000@peter.localdomain>
|
||
To: Peter Eisentraut <peter_e@gmx.net>
|
||
Date: Thu, 24 Jan 2002 23:33:52 -0500 (EST)
|
||
cc: Tom Lane <tgl@sss.pgh.pa.us>,
|
||
Zeugswetter Andreas SB SD <ZeugswetterA@spardat.at>,
|
||
Fernando Nasser <fnasser@redhat.com>, pgsql-hackers@postgresql.org
|
||
X-Mailer: ELM [version 2.4ME+ PL96 (25)]
|
||
MIME-Version: 1.0
|
||
Content-Transfer-Encoding: 7bit
|
||
Content-Type: text/plain; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Peter Eisentraut wrote:
|
||
> Tom Lane writes:
|
||
>
|
||
> > It'd be nice though if
|
||
> > the behavior could be changed after connection by a SET statement, which
|
||
> > would be lots easier if the setting were GUC-controlled. Peter, you see
|
||
> > any way to resolve that?
|
||
>
|
||
> We had a text[] field to pg_shadow and/or pg_database containing
|
||
> name=value assignments which are executed just before the session starts.
|
||
> Doesn't look terribly difficult, and it's something I've always wanted to
|
||
> do anyway.
|
||
|
||
So are thinking of "dbname=schema_type"? Seems this is really something
|
||
that should be in pg_database. If you create a database, who wants to
|
||
edit postgresql.conf to set its default schema type? Why not set the
|
||
GUC value from pg_database?
|
||
|
||
--
|
||
Bruce Momjian | http://candle.pha.pa.us
|
||
pgman@candle.pha.pa.us | (610) 853-3000
|
||
+ If your life is a hard drive, | 830 Blythe Avenue
|
||
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 5: Have you checked our extensive FAQ?
|
||
|
||
http://www.postgresql.org/users-lounge/docs/faq.html
|
||
|
||
From pgsql-hackers-owner+M18165=candle.pha.pa.us=pgman@postgresql.org Fri Jan 25 00:33:36 2002
|
||
Return-path: <pgsql-hackers-owner+M18165=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0P5XZe14335
|
||
for <pgman@candle.pha.pa.us>; Fri, 25 Jan 2002 00:33:36 -0500 (EST)
|
||
Received: (qmail 15579 invoked by alias); 25 Jan 2002 05:33:30 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 25 Jan 2002 05:33:30 -0000
|
||
Received: from student.gvsu.edu ([148.61.7.124])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0P5Oul14811
|
||
for <pgsql-hackers@postgreSQL.org>; Fri, 25 Jan 2002 00:24:56 -0500 (EST)
|
||
(envelope-from peter_e@gmx.net)
|
||
Received: from [148.61.250.128] [148.61.250.128] by student.gvsu.edu
|
||
with Novonyx SMTP Server $Revision: 1.3 $; Fri, 25 Jan 2002 00:25:01 -0500 (EDT)
|
||
Date: Fri, 25 Jan 2002 00:27:07 -0500 (EST)
|
||
From: Peter Eisentraut <peter_e@gmx.net>
|
||
X-Sender: <peter@peter.localdomain>
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Bill Studenmund <wrstuden@netbsd.org>, <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <8842.1011822361@sss.pgh.pa.us>
|
||
Message-ID: <Pine.LNX.4.30.0201250013040.686-100000@peter.localdomain>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Tom Lane writes:
|
||
|
||
> There could be multiple valid interpretations. When you can't even
|
||
> figure out where to start, it's too squishy for me. Code complexity
|
||
> isn't really the issue here, it's whether a user can understand what's
|
||
> going on.
|
||
|
||
Here's a tricky question: In what situations is a.b valid to mean b(a)?
|
||
Because in a general object-like system you could write a.b.c.d to mean
|
||
d(c(b(a))). There you've got a system where it's really impossible to
|
||
tell anything. Maybe b() returns a table, so a.b.c.d could mean
|
||
subattribute d in column c in the table returned by b(a).
|
||
|
||
Somehow we need to do at least one of three things:
|
||
1. Require parentheses after function calls.
|
||
2. Use a different operator to invoke function calls (SQL uses ->).
|
||
3. Require users to register functions as "methods" with the data type
|
||
before being able to say a.b for b(a). This also takes care of having to
|
||
specify the schema of b because that's declared when you define the
|
||
method.
|
||
|
||
SQL99 does 2 and 3 (but not 1).
|
||
|
||
I say, forget Oracle. Oracle doesn't have all the extensibility
|
||
functionality that PostgreSQL has. Let's build a system that is
|
||
consistent, orthogonal, and easy to use for *our* users, and those that
|
||
want to convert will quickly see the value.
|
||
|
||
--
|
||
Peter Eisentraut peter_e@gmx.net
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 4: Don't 'kill -9' the postmaster
|
||
|
||
From pgsql-hackers-owner+M18166=candle.pha.pa.us=pgman@postgresql.org Fri Jan 25 00:43:38 2002
|
||
Return-path: <pgsql-hackers-owner+M18166=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0P5hce15000
|
||
for <pgman@candle.pha.pa.us>; Fri, 25 Jan 2002 00:43:38 -0500 (EST)
|
||
Received: (qmail 18028 invoked by alias); 25 Jan 2002 05:43:28 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 25 Jan 2002 05:43:28 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0P5eol16732
|
||
for <pgsql-hackers@postgreSQL.org>; Fri, 25 Jan 2002 00:40:50 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0P5eIf23724;
|
||
Fri, 25 Jan 2002 00:40:18 -0500 (EST)
|
||
To: Peter Eisentraut <peter_e@gmx.net>
|
||
cc: Bill Studenmund <wrstuden@netbsd.org>, pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <Pine.LNX.4.30.0201250013040.686-100000@peter.localdomain>
|
||
References: <Pine.LNX.4.30.0201250013040.686-100000@peter.localdomain>
|
||
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
|
||
message dated "Fri, 25 Jan 2002 00:27:07 -0500"
|
||
Date: Fri, 25 Jan 2002 00:40:18 -0500
|
||
Message-ID: <23721.1011937218@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Peter Eisentraut <peter_e@gmx.net> writes:
|
||
> Here's a tricky question: In what situations is a.b valid to mean b(a)?
|
||
|
||
I defined that in my first message on these issues: the last element
|
||
of a dotted-name string can be either a field name or a function
|
||
(which is applied to a table that's the next-to-last item). The
|
||
next-to-last element is always a table name.
|
||
|
||
> Because in a general object-like system you could write a.b.c.d to mean
|
||
> d(c(b(a))).
|
||
|
||
Indeed, that can happen now in Postgres, and as I pointed out we have
|
||
to get rid of it. That doesn't mean we need to eliminate the base case,
|
||
however.
|
||
|
||
> Somehow we need to do at least one of three things:
|
||
> 1. Require parentheses after function calls.
|
||
|
||
Breaks existing code unnecessarily.
|
||
|
||
> 2. Use a different operator to invoke function calls (SQL uses ->).
|
||
|
||
Breaks existing code unnecessarily.
|
||
|
||
> 3. Require users to register functions as "methods" with the data type
|
||
> before being able to say a.b for b(a). This also takes care of having to
|
||
> specify the schema of b because that's declared when you define the
|
||
> method.
|
||
|
||
Doesn't buy you anything unless you intend to reject function
|
||
overloading too. With overloading you may have multiple functions
|
||
b(something), so you still have to be able to determine what a is
|
||
without any context.
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 3: if posting/reading through Usenet, please send an appropriate
|
||
subscribe-nomail command to majordomo@postgresql.org so that your
|
||
message can get through to the mailing list cleanly
|
||
|
||
From pgsql-hackers-owner+M18168=candle.pha.pa.us=pgman@postgresql.org Fri Jan 25 01:13:24 2002
|
||
Return-path: <pgsql-hackers-owner+M18168=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0P6DNe17080
|
||
for <pgman@candle.pha.pa.us>; Fri, 25 Jan 2002 01:13:23 -0500 (EST)
|
||
Received: (qmail 22750 invoked by alias); 25 Jan 2002 06:13:23 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 25 Jan 2002 06:13:23 -0000
|
||
Received: from candle.pha.pa.us (216-55-132-35.dsl.san-diego.abac.net [216.55.132.35])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0P5tdl21299
|
||
for <pgsql-hackers@postgresql.org>; Fri, 25 Jan 2002 00:55:39 -0500 (EST)
|
||
(envelope-from pgman@candle.pha.pa.us)
|
||
Received: (from pgman@localhost)
|
||
by candle.pha.pa.us (8.11.6/8.10.1) id g0P5tWY15824;
|
||
Fri, 25 Jan 2002 00:55:32 -0500 (EST)
|
||
From: Bruce Momjian <pgman@candle.pha.pa.us>
|
||
Message-ID: <200201250555.g0P5tWY15824@candle.pha.pa.us>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <Pine.LNX.4.30.0201242259280.686-100000@peter.localdomain>
|
||
To: Peter Eisentraut <peter_e@gmx.net>
|
||
Date: Fri, 25 Jan 2002 00:55:32 -0500 (EST)
|
||
cc: Tom Lane <tgl@sss.pgh.pa.us>,
|
||
Zeugswetter Andreas SB SD <ZeugswetterA@spardat.at>,
|
||
Fernando Nasser <fnasser@redhat.com>, pgsql-hackers@postgresql.org
|
||
X-Mailer: ELM [version 2.4ME+ PL96 (25)]
|
||
MIME-Version: 1.0
|
||
Content-Transfer-Encoding: 7bit
|
||
Content-Type: text/plain; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Peter Eisentraut wrote:
|
||
> Tom Lane writes:
|
||
>
|
||
> > It'd be nice though if
|
||
> > the behavior could be changed after connection by a SET statement, which
|
||
> > would be lots easier if the setting were GUC-controlled. Peter, you see
|
||
> > any way to resolve that?
|
||
>
|
||
> We had a text[] field to pg_shadow and/or pg_database containing
|
||
> name=value assignments which are executed just before the session starts.
|
||
> Doesn't look terribly difficult, and it's something I've always wanted to
|
||
> do anyway.
|
||
|
||
Sorry, I see what you are saying now, that the name=value pairs would
|
||
set in pg_database and pg_shadow and get executed on session startup.
|
||
Very good.
|
||
|
||
--
|
||
Bruce Momjian | http://candle.pha.pa.us
|
||
pgman@candle.pha.pa.us | (610) 853-3000
|
||
+ If your life is a hard drive, | 830 Blythe Avenue
|
||
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 4: Don't 'kill -9' the postmaster
|
||
|
||
From pgsql-hackers-owner+M18174=candle.pha.pa.us=pgman@postgresql.org Fri Jan 25 06:44:17 2002
|
||
Return-path: <pgsql-hackers-owner+M18174=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0PBiGe20620
|
||
for <pgman@candle.pha.pa.us>; Fri, 25 Jan 2002 06:44:16 -0500 (EST)
|
||
Received: (qmail 92210 invoked by alias); 25 Jan 2002 11:43:41 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 25 Jan 2002 11:43:41 -0000
|
||
Received: from smxsat1.smxs.net (smxsat1.smxs.net [213.150.10.1])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0PBYsl90858
|
||
for <pgsql-hackers@postgresql.org>; Fri, 25 Jan 2002 06:34:54 -0500 (EST)
|
||
(envelope-from ZeugswetterA@spardat.at)
|
||
Received: from m01x1.s-mxs.net [10.3.55.201]
|
||
by smxsat1.smxs.net
|
||
with XWall v3.18f ;
|
||
Fri, 25 Jan 2002 12:36:18 +0100
|
||
Received: from m0102.s-mxs.net [10.3.55.2]
|
||
by m01x1.s-mxs.net
|
||
with XWall v3.18a ;
|
||
Fri, 25 Jan 2002 12:34:49 +0100
|
||
Received: from m0114.s-mxs.net ([10.3.55.14]) by m0102.s-mxs.net with Microsoft SMTPSVC(5.0.2195.2966);
|
||
Fri, 25 Jan 2002 12:34:49 +0100
|
||
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
|
||
content-class: urn:content-classes:message
|
||
MIME-Version: 1.0
|
||
Content-Type: text/plain;
|
||
charset="iso-8859-1"
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
Date: Fri, 25 Jan 2002 12:34:48 +0100
|
||
Message-ID: <46C15C39FEB2C44BA555E356FBCD6FA42128DD@m0114.s-mxs.net>
|
||
Thread-Topic: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
Thread-Index: AcGkLuTMcnCfXPmkTji5zHYd6Vhu3QBZTo9w
|
||
From: "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
|
||
To: "Joe Conway (wwc)" <jconway@cox.net>, "Tom Lane" <tgl@sss.pgh.pa.us>
|
||
cc: "Fernando Nasser" <fnasser@redhat.com>,
|
||
"Peter Eisentraut" <peter_e@gmx.net>, <pgsql-hackers@postgresql.org>
|
||
X-OriginalArrivalTime: 25 Jan 2002 11:34:49.0376 (UTC) FILETIME=[4C1C7200:01C1A594]
|
||
Content-Transfer-Encoding: 8bit
|
||
X-MIME-Autoconverted: from quoted-printable to 8bit by postgresql.org id g0PBh2m91415
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: ORr
|
||
|
||
|
||
> Tom Lane wrote:
|
||
>
|
||
> >
|
||
> > This would be a *whole* lot simpler if we forgot the notion of "any"
|
||
> > and made the search order look like
|
||
> >
|
||
> > (temp, private, public, system)
|
||
|
||
I am starting to see the advantages and like it. I also like the exact
|
||
name "public" for the public schema.
|
||
|
||
Andreas
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 5: Have you checked our extensive FAQ?
|
||
|
||
http://www.postgresql.org/users-lounge/docs/faq.html
|
||
|
||
From pgsql-hackers-owner+M18195=candle.pha.pa.us=pgman@postgresql.org Fri Jan 25 12:18:20 2002
|
||
Return-path: <pgsql-hackers-owner+M18195=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0PHIJe26232
|
||
for <pgman@candle.pha.pa.us>; Fri, 25 Jan 2002 12:18:19 -0500 (EST)
|
||
Received: (qmail 96791 invoked by alias); 25 Jan 2002 17:14:40 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 25 Jan 2002 17:14:40 -0000
|
||
Received: from candle.pha.pa.us (216-55-132-35.dsl.san-diego.abac.net [216.55.132.35])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0PGrXl88459
|
||
for <pgsql-hackers@postgresql.org>; Fri, 25 Jan 2002 11:53:34 -0500 (EST)
|
||
(envelope-from pgman@candle.pha.pa.us)
|
||
Received: (from pgman@localhost)
|
||
by candle.pha.pa.us (8.11.6/8.10.1) id g0PGq4L23522;
|
||
Fri, 25 Jan 2002 11:52:04 -0500 (EST)
|
||
From: Bruce Momjian <pgman@candle.pha.pa.us>
|
||
Message-ID: <200201251652.g0PGq4L23522@candle.pha.pa.us>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <46C15C39FEB2C44BA555E356FBCD6FA42128DD@m0114.s-mxs.net>
|
||
To: Zeugswetter Andreas SB SD <ZeugswetterA@spardat.at>
|
||
Date: Fri, 25 Jan 2002 11:52:04 -0500 (EST)
|
||
cc: "Joe Conway (wwc)" <jconway@cox.net>, Tom Lane <tgl@sss.pgh.pa.us>,
|
||
Fernando Nasser <fnasser@redhat.com>, Peter Eisentraut <peter_e@gmx.net>,
|
||
pgsql-hackers@postgresql.org
|
||
X-Mailer: ELM [version 2.4ME+ PL96 (25)]
|
||
MIME-Version: 1.0
|
||
Content-Transfer-Encoding: 7bit
|
||
Content-Type: text/plain; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Zeugswetter Andreas SB SD wrote:
|
||
>
|
||
> > Tom Lane wrote:
|
||
> >
|
||
> > >
|
||
> > > This would be a *whole* lot simpler if we forgot the notion of "any"
|
||
> > > and made the search order look like
|
||
> > >
|
||
> > > (temp, private, public, system)
|
||
>
|
||
> I am starting to see the advantages and like it. I also like the exact
|
||
> name "public" for the public schema.
|
||
|
||
I wonder if we should think about a 'group' area so people in a group
|
||
can create things that others in the group can see, but not people
|
||
outside the group.
|
||
|
||
--
|
||
Bruce Momjian | http://candle.pha.pa.us
|
||
pgman@candle.pha.pa.us | (610) 853-3000
|
||
+ If your life is a hard drive, | 830 Blythe Avenue
|
||
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 3: if posting/reading through Usenet, please send an appropriate
|
||
subscribe-nomail command to majordomo@postgresql.org so that your
|
||
message can get through to the mailing list cleanly
|
||
|
||
From tgl@sss.pgh.pa.us Fri Jan 25 12:04:14 2002
|
||
Return-path: <tgl@sss.pgh.pa.us>
|
||
Received: from sss.pgh.pa.us (root@[192.204.191.242])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g0PH4De25154
|
||
for <pgman@candle.pha.pa.us>; Fri, 25 Jan 2002 12:04:13 -0500 (EST)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0PH4Cf26410;
|
||
Fri, 25 Jan 2002 12:04:12 -0500 (EST)
|
||
To: Bruce Momjian <pgman@candle.pha.pa.us>
|
||
cc: Zeugswetter Andreas SB SD <ZeugswetterA@spardat.at>,
|
||
"Joe Conway (wwc)" <jconway@cox.net>, Fernando Nasser <fnasser@redhat.com>,
|
||
Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <200201251652.g0PGq4L23522@candle.pha.pa.us>
|
||
References: <200201251652.g0PGq4L23522@candle.pha.pa.us>
|
||
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
|
||
message dated "Fri, 25 Jan 2002 11:52:04 -0500"
|
||
Date: Fri, 25 Jan 2002 12:04:12 -0500
|
||
Message-ID: <26407.1011978252@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Status: OR
|
||
|
||
Bruce Momjian <pgman@candle.pha.pa.us> writes:
|
||
>> I am starting to see the advantages and like it. I also like the exact
|
||
>> name "public" for the public schema.
|
||
|
||
> I wonder if we should think about a 'group' area so people in a group
|
||
> can create things that others in the group can see, but not people
|
||
> outside the group.
|
||
|
||
I see no reason to hard-wire such a concept. Given createable
|
||
namespaces, ACLs for namespaces, and a settable namespace search path,
|
||
people can set up group namespaces or anything else they want.
|
||
|
||
The (temp, private, public, system) path is suggested as default because
|
||
it's the minimum we need to support both SQL92 and backwards-compatible
|
||
behaviors. I don't think we should put in special-purpose features
|
||
beyond that, when we can instead offer a general mechanism with which
|
||
people can build the special-purpose features they want.
|
||
|
||
regards, tom lane
|
||
|
||
From pgsql-hackers-owner+M18209=candle.pha.pa.us=pgman@postgresql.org Fri Jan 25 16:14:02 2002
|
||
Return-path: <pgsql-hackers-owner+M18209=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0PLE1e19183
|
||
for <pgman@candle.pha.pa.us>; Fri, 25 Jan 2002 16:14:01 -0500 (EST)
|
||
Received: (qmail 85059 invoked by alias); 25 Jan 2002 21:13:58 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 25 Jan 2002 21:13:58 -0000
|
||
Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0PKtNl77878
|
||
for <pgsql-hackers@postgresql.org>; Fri, 25 Jan 2002 15:55:23 -0500 (EST)
|
||
(envelope-from wrstuden@netbsd.org)
|
||
Received: (qmail 10628 invoked by uid 1130); 25 Jan 2002 20:55:14 -0000
|
||
Date: Fri, 25 Jan 2002 12:50:26 -0800 (PST)
|
||
From: Bill Studenmund <wrstuden@netbsd.org>
|
||
X-X-Sender: <wrstuden@vespasia.home-net.internetconnect.net>
|
||
To: Gavin Sherry <swm@linuxworld.com.au>
|
||
cc: Tom Lane <tgl@sss.pgh.pa.us>, <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <Pine.LNX.4.21.0201251517350.12632-100000@linuxworld.com.au>
|
||
Message-ID: <Pine.NEB.4.33.0201251241140.12100-100000@vespasia.home-net.internetconnect.net>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Fri, 25 Jan 2002, Gavin Sherry wrote:
|
||
|
||
> This makes a lot of sense and suggests the possibility of 'schema enabled'
|
||
> databases. That is, a switch 'bool withschemas' (which defaults to
|
||
> false) could be added to pg_database. If true, the parser and ownership
|
||
> model reflects that of SQL'99 and/or the Postgres schema model. If false,
|
||
> the existing 'schema' model is assumed.
|
||
>
|
||
> This should allow existing users to migrate their data and applications to
|
||
> 7.3 without having to modify either.
|
||
>
|
||
> Its not an ideal solution but backward compatibility is generally results
|
||
> in compromise ;).
|
||
|
||
I guess my frustration with this idea is that we don't really need it. We
|
||
can achieve the same global namespace for an old app without it. All we
|
||
need is a tool which turns old dumps into new ones (which we probably need
|
||
anyway) that merges all of the schemas together w/ PATH statements. Or
|
||
maybe (new idea) a tool which looks at the schemas in a DB and updates
|
||
their PATHs so they act unified.
|
||
|
||
We can achieve the old behavior w/o having to build it into the backend.
|
||
So why add code to the backend when we don't have to? Among other things,
|
||
it would complicate the system schema as we'd have to keep track of
|
||
ownership values we wouldn't otherwise need to.
|
||
|
||
Take care,
|
||
|
||
Bill
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 4: Don't 'kill -9' the postmaster
|
||
|
||
From ZeugswetterA@spardat.at Fri Jan 25 16:36:49 2002
|
||
Return-path: <ZeugswetterA@spardat.at>
|
||
Received: from smxsat1.smxs.net (smxsat1.smxs.net [213.150.10.1])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g0PLame20819
|
||
for <pgman@candle.pha.pa.us>; Fri, 25 Jan 2002 16:36:48 -0500 (EST)
|
||
Received: from m01x1.s-mxs.net [10.3.55.201]
|
||
by smxsat1.smxs.net
|
||
with XWall v3.18f ;
|
||
Fri, 25 Jan 2002 22:38:07 +0100
|
||
Received: from m0102.s-mxs.net [10.3.55.2]
|
||
by m01x1.s-mxs.net
|
||
with XWall v3.18a ;
|
||
Fri, 25 Jan 2002 22:36:38 +0100
|
||
Received: from m0114.s-mxs.net ([10.3.55.14]) by m0102.s-mxs.net with Microsoft SMTPSVC(5.0.2195.2966);
|
||
Fri, 25 Jan 2002 22:36:38 +0100
|
||
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
|
||
content-class: urn:content-classes:message
|
||
MIME-Version: 1.0
|
||
Content-Type: text/plain;
|
||
charset="iso-8859-1"
|
||
Subject: RE: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
Date: Fri, 25 Jan 2002 22:36:37 +0100
|
||
Message-ID: <46C15C39FEB2C44BA555E356FBCD6FA42128E0@m0114.s-mxs.net>
|
||
Thread-Topic: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
Thread-Index: AcGlwKXMNIw3BiZ7R4G6MaOhn/ahAgAJ0maA
|
||
From: "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
|
||
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
|
||
cc: "Joe Conway (wwc)" <jconway@cox.net>, "Tom Lane" <tgl@sss.pgh.pa.us>,
|
||
"Fernando Nasser" <fnasser@redhat.com>,
|
||
"Peter Eisentraut" <peter_e@gmx.net>, <pgsql-hackers@postgresql.org>
|
||
X-OriginalArrivalTime: 25 Jan 2002 21:36:38.0285 (UTC) FILETIME=[5EB2B3D0:01C1A5E8]
|
||
Content-Transfer-Encoding: 8bit
|
||
X-MIME-Autoconverted: from quoted-printable to 8bit by candle.pha.pa.us id g0PLame20819
|
||
Status: OR
|
||
|
||
|
||
> > I am starting to see the advantages and like it. I also like the exact
|
||
> > name "public" for the public schema.
|
||
>
|
||
> I wonder if we should think about a 'group' area so people in a group
|
||
> can create things that others in the group can see, but not people
|
||
> outside the group.
|
||
|
||
A group simply chooses a special schema name for their group.
|
||
|
||
Maybe an extra in the ACL area so you can grant privs for a whole
|
||
schema.
|
||
|
||
grant select on schema blabla to "JoeLuser"
|
||
|
||
Andreas
|
||
|
||
From wrstuden@netbsd.org Fri Jan 25 17:12:51 2002
|
||
Return-path: <wrstuden@netbsd.org>
|
||
Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0PMCoe23588
|
||
for <pgman@candle.pha.pa.us>; Fri, 25 Jan 2002 17:12:51 -0500 (EST)
|
||
Received: (qmail 20909 invoked by uid 1130); 25 Jan 2002 22:12:46 -0000
|
||
Date: Fri, 25 Jan 2002 14:07:58 -0800 (PST)
|
||
From: Bill Studenmund <wrstuden@netbsd.org>
|
||
X-X-Sender: <wrstuden@vespasia.home-net.internetconnect.net>
|
||
To: Bruce Momjian <pgman@candle.pha.pa.us>
|
||
cc: Tom Lane <tgl@sss.pgh.pa.us>,
|
||
Zeugswetter Andreas SB SD <ZeugswetterA@spardat.at>,
|
||
Fernando Nasser <fnasser@redhat.com>, Peter Eisentraut <peter_e@gmx.net>,
|
||
<pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <200201250326.g0P3Qhw23061@candle.pha.pa.us>
|
||
Message-ID: <Pine.NEB.4.33.0201251358390.12100-100000@vespasia.home-net.internetconnect.net>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Status: OR
|
||
|
||
On Thu, 24 Jan 2002, Bruce Momjian wrote:
|
||
|
||
> I think we could set the database default at db creation time, then
|
||
> allow SET to modify that default per session; seems flexible enough.
|
||
> It is basically a GUC value who's default is stored in pg_database
|
||
> rather than postgresql.conf. You could use postgresql.conf to set the
|
||
> default schema type at db creation time.
|
||
|
||
Specifically to the question of schema pathing, why would you want it to
|
||
be session-settable? Either your DB app is designed to work w/ schemas, or
|
||
it isn't. That's a pretty fundamental design concept. Given that, I don't
|
||
see how it can make sense to try to operate in the opposite mode as the
|
||
app was designed for - that'll only lead to chaos.
|
||
|
||
Take care,
|
||
|
||
Bill
|
||
|
||
|
||
From tgl@sss.pgh.pa.us Fri Jan 25 17:26:17 2002
|
||
Return-path: <tgl@sss.pgh.pa.us>
|
||
Received: from sss.pgh.pa.us (root@[192.204.191.242])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g0PMQGe24836
|
||
for <pgman@candle.pha.pa.us>; Fri, 25 Jan 2002 17:26:16 -0500 (EST)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0PMQEf07711;
|
||
Fri, 25 Jan 2002 17:26:14 -0500 (EST)
|
||
To: Bill Studenmund <wrstuden@netbsd.org>
|
||
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
|
||
Zeugswetter Andreas SB SD <ZeugswetterA@spardat.at>,
|
||
Fernando Nasser <fnasser@redhat.com>, Peter Eisentraut <peter_e@gmx.net>,
|
||
pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <Pine.NEB.4.33.0201251358390.12100-100000@vespasia.home-net.internetconnect.net>
|
||
References: <Pine.NEB.4.33.0201251358390.12100-100000@vespasia.home-net.internetconnect.net>
|
||
Comments: In-reply-to Bill Studenmund <wrstuden@netbsd.org>
|
||
message dated "Fri, 25 Jan 2002 14:07:58 -0800"
|
||
Date: Fri, 25 Jan 2002 17:26:14 -0500
|
||
Message-ID: <7708.1011997574@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Status: OR
|
||
|
||
Bill Studenmund <wrstuden@netbsd.org> writes:
|
||
> Specifically to the question of schema pathing, why would you want it to
|
||
> be session-settable? Either your DB app is designed to work w/ schemas, or
|
||
> it isn't.
|
||
|
||
So that you can set the correct mode for your client application. It is
|
||
silly to suppose that an installation-wide or even database-wide setting
|
||
is sufficient. Consider for example a database shared by multiple
|
||
pieces of client software; wouldn't you like to be able to upgrade them
|
||
to schema-awareness one at a time?
|
||
|
||
You could possibly make a case for a single setting per user, but even
|
||
that makes an assumption (user == client software) that I think is not
|
||
reasonable for us to force on all Postgres installations.
|
||
|
||
Basically I haven't got a lot of patience for arguments that say we do
|
||
not need flexibility. There are more people out there, using Postgres
|
||
in more different ways, than either you or I know about.
|
||
|
||
regards, tom lane
|
||
|
||
From pgsql-hackers-owner+M18216=candle.pha.pa.us=pgman@postgresql.org Fri Jan 25 18:54:34 2002
|
||
Return-path: <pgsql-hackers-owner+M18216=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0PNsXe02286
|
||
for <pgman@candle.pha.pa.us>; Fri, 25 Jan 2002 18:54:34 -0500 (EST)
|
||
Received: (qmail 18323 invoked by alias); 25 Jan 2002 23:53:56 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 25 Jan 2002 23:53:56 -0000
|
||
Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0PNk1l17143
|
||
for <pgsql-hackers@postgresql.org>; Fri, 25 Jan 2002 18:46:02 -0500 (EST)
|
||
(envelope-from wrstuden@netbsd.org)
|
||
Received: (qmail 23281 invoked by uid 1130); 25 Jan 2002 23:46:04 -0000
|
||
Date: Fri, 25 Jan 2002 15:41:16 -0800 (PST)
|
||
From: Bill Studenmund <wrstuden@netbsd.org>
|
||
X-X-Sender: <wrstuden@vespasia.home-net.internetconnect.net>
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
|
||
Zeugswetter Andreas SB SD <ZeugswetterA@spardat.at>,
|
||
Fernando Nasser <fnasser@redhat.com>, Peter Eisentraut <peter_e@gmx.net>,
|
||
<pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <7708.1011997574@sss.pgh.pa.us>
|
||
Message-ID: <Pine.NEB.4.33.0201251425391.12100-100000@vespasia.home-net.internetconnect.net>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Fri, 25 Jan 2002, Tom Lane wrote:
|
||
|
||
> Bill Studenmund <wrstuden@netbsd.org> writes:
|
||
> > Specifically to the question of schema pathing, why would you want it to
|
||
> > be session-settable? Either your DB app is designed to work w/ schemas, or
|
||
> > it isn't.
|
||
>
|
||
> So that you can set the correct mode for your client application. It is
|
||
> silly to suppose that an installation-wide or even database-wide setting
|
||
> is sufficient. Consider for example a database shared by multiple
|
||
> pieces of client software; wouldn't you like to be able to upgrade them
|
||
> to schema-awareness one at a time?
|
||
|
||
What exactly does it mean to upgrade to schema-awareness? I know the jist
|
||
of what you mean, but what does it entail? What steps? I ask as, when I
|
||
think of what it means in practical steps, an upgraded app won't have
|
||
problems with extra stuff pathed in. So the upgraded app will be fine with
|
||
the pathing set up to include all (not-upgraded) schemas. Also, if it does
|
||
have a problem with stuff pathed in, since you can easily set the new apps
|
||
up to live in different schemas than the old ones, you can have upgraded &
|
||
from-before schemas.
|
||
|
||
> You could possibly make a case for a single setting per user, but even
|
||
> that makes an assumption (user == client software) that I think is not
|
||
> reasonable for us to force on all Postgres installations.
|
||
|
||
But we will have the ability to set the path per schema. Since
|
||
schema-aware apps should be able to choose which schema they connect to (I
|
||
envision it being a connect parameter), the different apps can implicitly
|
||
get different behaviors by connecting to schemas that are designed to be
|
||
schema-savy, or connecting to ones which aren't (i.e. have all of the
|
||
schema-unaware stuff pathed in).
|
||
|
||
> Basically I haven't got a lot of patience for arguments that say we do
|
||
> not need flexibility. There are more people out there, using Postgres
|
||
> in more different ways, than either you or I know about.
|
||
|
||
Tom, please listen to what I'm saying. I'm trying to be as clear as I can
|
||
& making sure I'm not working from details in my head and not my posts.
|
||
I'm sorry if it isn't clear but I'm _not_ saying that we don't need the
|
||
flexability you describe. We do.
|
||
|
||
I'm saying that IT IS ALREADY THERE! The pathing built into schemas can be
|
||
very powerful. Powerful enough that I haven't heard of an example yet that
|
||
can't be taken care of with judicious use of pathing. And I don't think
|
||
the pathing needed is beyond mid-level admins (I don't see it as something
|
||
which only say 5 people on the lists can get right). Yes, people will have
|
||
to learn it, but it doesn't strike me as that hard a thing.
|
||
|
||
What I am saying is that we don't need the solution you & Bruce mentioned
|
||
to get the flexability you mentioned as the reason for adding it. So why
|
||
add the feature which isn't needed?
|
||
|
||
One of my objections to a "mode" supporting the old behavior is that, as I
|
||
understand it, there would be a schema ("public") where different users
|
||
could own objects in the same schema. That goes against one of the
|
||
advantages I see for schemas: we can consolidate ownership info in the
|
||
system tables. If you know what schema something is in, you know its
|
||
owner. That means that adding schema support doesn't mean growing system
|
||
tables, just renaming a column (the user id gets turned into the schema
|
||
id).
|
||
|
||
Maybe that's not such a big deal. But it seems when we're doing things
|
||
right, things should get cleaner. Having to keep ownership info at both
|
||
the schema level and at the object level strikes me as not making things
|
||
cleaner. That just seems to be going in the wrong direction.
|
||
|
||
Especially as, AFAICT, it wouldn't be hard to let the sysadmins have all
|
||
the flexability you want them to have (and also that I agree they should
|
||
have) in a system which is, at its core, very schema-savy (everything in
|
||
one schema is owned by the same user or group).
|
||
|
||
I also agree that migration is important. Apps from 7.2 (and 7.1 and
|
||
earlier as possible) should run on the schema-savy backend I describe. A
|
||
migration tool to take the dump from before and add update schema commands
|
||
to path everything in (so it looks like one namespace) should make the old
|
||
apps keep working.
|
||
|
||
The one thing I'll concede could be useful would be for createuser to be
|
||
told to automatically set the new user's schema to include all the other
|
||
schemas, and to update all the other user schemas to add this user. That
|
||
way you can add new users to your DB when you're acting as if it didn't
|
||
have schemas.
|
||
|
||
Hmmm. If we made the above behavior a per-db-configurable default, the
|
||
pg_dump file wouldn't need to be changed. That would be good. It would
|
||
make the path updates O(nusers^2) rather than O(nusers), but that probably
|
||
won't be bad. And offering both options would probably be good.
|
||
|
||
Take care,
|
||
|
||
Bill
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 2: you can get off all lists at once with the unregister command
|
||
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
|
||
|
||
From tgl@sss.pgh.pa.us Fri Jan 25 19:04:17 2002
|
||
Return-path: <tgl@sss.pgh.pa.us>
|
||
Received: from sss.pgh.pa.us (root@[192.204.191.242])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g0Q04Ge02926
|
||
for <pgman@candle.pha.pa.us>; Fri, 25 Jan 2002 19:04:17 -0500 (EST)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0Q04Ff08236;
|
||
Fri, 25 Jan 2002 19:04:16 -0500 (EST)
|
||
To: Bill Studenmund <wrstuden@netbsd.org>
|
||
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
|
||
Zeugswetter Andreas SB SD <ZeugswetterA@spardat.at>,
|
||
Fernando Nasser <fnasser@redhat.com>, Peter Eisentraut <peter_e@gmx.net>,
|
||
pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <Pine.NEB.4.33.0201251425391.12100-100000@vespasia.home-net.internetconnect.net>
|
||
References: <Pine.NEB.4.33.0201251425391.12100-100000@vespasia.home-net.internetconnect.net>
|
||
Comments: In-reply-to Bill Studenmund <wrstuden@netbsd.org>
|
||
message dated "Fri, 25 Jan 2002 15:41:16 -0800"
|
||
Date: Fri, 25 Jan 2002 19:04:15 -0500
|
||
Message-ID: <8233.1012003455@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Status: OR
|
||
|
||
Bill Studenmund <wrstuden@netbsd.org> writes:
|
||
> But we will have the ability to set the path per schema.
|
||
|
||
?? I don't follow that at all. A namespace is something that's referred
|
||
to by a search path, not vice versa. Or are you defining "schema" to
|
||
mean some higher-level concept that incorporates a search path of
|
||
multiple primitive namespaces? Maybe that could work, but I'm not sure
|
||
I see the point yet.
|
||
|
||
regards, tom lane
|
||
|
||
From wrstuden@netbsd.org Fri Jan 25 20:39:59 2002
|
||
Return-path: <wrstuden@netbsd.org>
|
||
Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0Q1dve10731
|
||
for <pgman@candle.pha.pa.us>; Fri, 25 Jan 2002 20:39:58 -0500 (EST)
|
||
Received: (qmail 27927 invoked by uid 1130); 26 Jan 2002 01:39:59 -0000
|
||
Date: Fri, 25 Jan 2002 17:35:11 -0800 (PST)
|
||
From: Bill Studenmund <wrstuden@netbsd.org>
|
||
X-X-Sender: <wrstuden@vespasia.home-net.internetconnect.net>
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
|
||
Zeugswetter Andreas SB SD <ZeugswetterA@spardat.at>,
|
||
Fernando Nasser <fnasser@redhat.com>, Peter Eisentraut <peter_e@gmx.net>,
|
||
<pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <8233.1012003455@sss.pgh.pa.us>
|
||
Message-ID: <Pine.NEB.4.33.0201251631050.12100-100000@vespasia.home-net.internetconnect.net>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Status: OR
|
||
|
||
On Fri, 25 Jan 2002, Tom Lane wrote:
|
||
|
||
> Bill Studenmund <wrstuden@netbsd.org> writes:
|
||
> > But we will have the ability to set the path per schema.
|
||
>
|
||
> ?? I don't follow that at all. A namespace is something that's referred
|
||
> to by a search path, not vice versa. Or are you defining "schema" to
|
||
> mean some higher-level concept that incorporates a search path of
|
||
> multiple primitive namespaces? Maybe that could work, but I'm not sure
|
||
> I see the point yet.
|
||
|
||
Oh. That would make a difference. We've been talking past each other.
|
||
|
||
SQL schemas, as I understand the spec, are both. A shema is a container
|
||
that holds things like tables and views and functions (and for PostgreSQL
|
||
operators and aggregates and I'd suggest index operators, etc.). It also
|
||
can include a schema path specification, which defines the search path
|
||
used by routines (stored procedures & functions) contained in that schema.
|
||
|
||
So say I have schemas foo, bar, and baz. I can set the schema path for
|
||
schema bar to be foo:bar:baz:IMPLIMENTATION_SCHEMA, and all routines in
|
||
bar will look in those four schemas for types, functions and tables (and
|
||
everything else we use the search path for).
|
||
|
||
(*) IMPLIMENTATION_SCHEMA is required by the spec, and contains all the
|
||
built-ins. It's be implimentation_schema for pg. Also, if you have a path
|
||
that doesn't list it, the db is supposed to prepend it to the list.
|
||
|
||
So when migrating an app from a schema-unaware PostgreSQL to a
|
||
schema-aware one, if we create a schema for each user, and make each
|
||
such schema path in all the other such schemas, we make it such that all
|
||
of the procedures in those schemas act like they have a unified namespace.
|
||
|
||
There also is also the concept of the CURRENT_PATH which is the schema
|
||
path used for parsed queries (like ones typed into psql). I got lost in
|
||
the spec trying to find what this is supposed to default to, but what I
|
||
understand other DBs to do is your CURRENT_PATH is set to the path of the
|
||
schema you log into.
|
||
|
||
Add to this mix the default schema for user X is schema X (which I thought
|
||
was in the spec but I can't find now), and let's look at that example
|
||
again.
|
||
|
||
Say we had users foo, bar and baz before. We made schemas foo, bar, and
|
||
baz. We set the default paths for each of these schemas to
|
||
foo:bar:baz:IMPLIMENTATION_SCHEMA. Now the routines in each of these
|
||
schemas will see a unified namespace. Next, when we log in as users foo,
|
||
bar, or baz, and our CURRENT_PATH ends up including the namespaces of the
|
||
three original users. So now all of our submitted queries also see a
|
||
unified namespace.
|
||
|
||
So with a schema-savy backend, by adding PATH statements to the schemas
|
||
that pull in all of the previous schemas, we can make the old app behave
|
||
as if it had a unified namespace.
|
||
|
||
Does that make sense?
|
||
|
||
Take care,
|
||
|
||
Bill
|
||
|
||
P.S. does anyone need copies of the spec? I found pdf's on the web a while
|
||
back..
|
||
|
||
|
||
From pgsql-hackers-owner+M18221=candle.pha.pa.us=pgman@postgresql.org Fri Jan 25 22:13:58 2002
|
||
Return-path: <pgsql-hackers-owner+M18221=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0Q3Dwe17302
|
||
for <pgman@candle.pha.pa.us>; Fri, 25 Jan 2002 22:13:58 -0500 (EST)
|
||
Received: (qmail 42344 invoked by alias); 26 Jan 2002 03:13:55 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 26 Jan 2002 03:13:55 -0000
|
||
Received: from golem.fourpalms.org (golem.fourpalms.org [64.3.68.148])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0Q35hl41629
|
||
for <pgsql-hackers@postgresql.org>; Fri, 25 Jan 2002 22:05:43 -0500 (EST)
|
||
(envelope-from lockhart@fourpalms.org)
|
||
Received: from fourpalms.org (localhost.localdomain [127.0.0.1])
|
||
by golem.fourpalms.org (Postfix) with ESMTP
|
||
id 0336CFEC5; Sat, 26 Jan 2002 03:05:45 +0000 (UTC)
|
||
Message-ID: <3C521D08.9138E2EA@fourpalms.org>
|
||
Date: Sat, 26 Jan 2002 03:05:44 +0000
|
||
From: Thomas Lockhart <lockhart@fourpalms.org>
|
||
Reply-To: lockhart@fourpalms.org
|
||
Organization: Yes
|
||
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17-21mdksmp i686)
|
||
X-Accept-Language: en
|
||
MIME-Version: 1.0
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Stephan Szabo <sszabo@megazone23.bigpanda.com>,
|
||
Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org,
|
||
Fernando Nasser <fnasser@redhat.com>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
References: <20020123083152.W18169-100000@megazone23.bigpanda.com> <3159.1011804418@sss.pgh.pa.us>
|
||
Content-Type: text/plain; charset=us-ascii
|
||
Content-Transfer-Encoding: 7bit
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
...
|
||
> > Wouldn't it make sense to prefer operators/functions earlier in the search
|
||
> > path for resolving ambiguity. So if you had plus(int4, int4) in my
|
||
> > schema and plus(int8, int8) in system, and they'd otherwise cause an
|
||
> > ambiguity failure for the query, use the plus(int4, int4) on mine. It
|
||
> > seems not too far from having the search path shadow later exact matches.
|
||
> Given the complexity of the resolution rules (cf.
|
||
> http://developer.postgresql.org/docs/postgres/typeconv.html),
|
||
> it's not clear that we can determine exactly which "later" entry ought
|
||
> to be blamed for causing a resolution failure. I'd be interested to
|
||
> hear Lockhart's opinion on this --- but my gut feeling is we don't
|
||
> want to go there. The resolution rules are already complicated enough,
|
||
> and I think layering an additional mechanism like that onto them might
|
||
> make the behavior totally unpredictable.
|
||
|
||
(I've been following the discussion; I suspect that this part may
|
||
already have an obvious answer since "any" scoping -- equivalent to
|
||
flattening the namespace? -- may now be out of favor; I'm assuming that
|
||
we have a clearly scoped lookup scheme available).
|
||
|
||
imho there is nothing fundamentally difficult or "unpredictable" about
|
||
layering schema lookup on to the existing function resolution rules. One
|
||
might want a bit better diagnostics about *which* function was actually
|
||
chosen, but reasonable scoping and lookup rules could be constructed
|
||
which give reasonable behavior with the addition of schemas.
|
||
|
||
For example, the current function resolution rules prefer an exact
|
||
match, then start looking for approximate matches, and narrow that down
|
||
to preferring the one with the best explicit match on data types. If
|
||
more than one matches, then it rejects the query. (I've left out one or
|
||
two steps, but on the whole this is the behavior that matters.)
|
||
|
||
With schemas, one could choose to use "closest schema" as the tiebreaker
|
||
for multiple matches, but istm that an exact match should always win.
|
||
|
||
We might want to include a mechanism that *blocks* schema lookups deeper
|
||
into the search path, to allow reliable *complete replacement* of a
|
||
function. This would be a property of the function, to be set when it is
|
||
defined in the schema. So an implementer could choose to restrict
|
||
lookups explicitly if that is deemed necessary. Again, this is not a
|
||
huge complication.
|
||
|
||
It is an interesting discussion, and the fine points will not be brought
|
||
out without having lots of back-and-forth, which seems to be happening
|
||
already ;)
|
||
|
||
- Thomas
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 4: Don't 'kill -9' the postmaster
|
||
|
||
From pgsql-hackers-owner+M18236=candle.pha.pa.us=pgman@postgresql.org Sun Jan 27 20:44:07 2002
|
||
Return-path: <pgsql-hackers-owner+M18236=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0S1i6e21103
|
||
for <pgman@candle.pha.pa.us>; Sun, 27 Jan 2002 20:44:06 -0500 (EST)
|
||
Received: (qmail 86523 invoked by alias); 28 Jan 2002 01:44:01 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 28 Jan 2002 01:44:01 -0000
|
||
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0S1X4l84668
|
||
for <pgsql-hackers@postgreSQL.org>; Sun, 27 Jan 2002 20:33:04 -0500 (EST)
|
||
(envelope-from Inoue@tpf.co.jp)
|
||
Received: (qmail 4010 invoked from network); 28 Jan 2002 01:33:07 -0000
|
||
Received: from unknown (HELO viscomail.tpf.co.jp) (100.0.0.108)
|
||
by sd2.tpf-fw-c.co.jp with SMTP; 28 Jan 2002 01:33:07 -0000
|
||
Received: from tpf.co.jp (3dgateway1 [126.0.1.60])
|
||
by viscomail.tpf.co.jp (8.8.8+Sun/8.8.8) with ESMTP id KAA05318;
|
||
Mon, 28 Jan 2002 10:33:04 +0900 (JST)
|
||
Message-ID: <3C54AA51.64CE68AD@tpf.co.jp>
|
||
Date: Mon, 28 Jan 2002 10:33:05 +0900
|
||
From: Hiroshi Inoue <Inoue@tpf.co.jp>
|
||
X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U)
|
||
X-Accept-Language: ja
|
||
MIME-Version: 1.0
|
||
To: Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Bill Studenmund <wrstuden@netbsd.org>,
|
||
Stephan Szabo <sszabo@megazone23.bigpanda.com>,
|
||
PostgreSQL Development <pgsql-hackers@postgresql.org>,
|
||
Fernando Nasser <fnasser@redhat.com>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
References: <Pine.LNX.4.30.0201240003120.686-100000@peter.localdomain>
|
||
Content-Type: text/plain; charset=iso-2022-jp
|
||
Content-Transfer-Encoding: 7bit
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Is *the path* below the same as "search path* in other
|
||
postings about this thread ?
|
||
|
||
Maybe Peter's posting isn't the one exactly what I have to
|
||
ask but there are too many postings for me to follow.
|
||
|
||
regards,
|
||
Hiroshi Inoue
|
||
|
||
Peter Eisentraut wrote:
|
||
>
|
||
> Bill Studenmund writes:
|
||
>
|
||
> > Does SQL'99 say anything about this?
|
||
>
|
||
> Yes, though, as usual, you have to twist your brain a little to understand
|
||
> it. My understanding is that for a function call of the form "foo(a, b)"
|
||
> it goes like this:
|
||
>
|
||
> 1. Find all functions named "foo" in the current database. This is the
|
||
> set of "possibly candidate routines".
|
||
>
|
||
> 2. Drop all routines that you do not have EXECUTE privilege for. This is
|
||
> the set of "executable routines".
|
||
>
|
||
> 3. Drop all routines that do not have compatible parameter lists. This is
|
||
> the set of "invocable routines".
|
||
>
|
||
> 4. Drop all routines whose schema is not in the path. This is the set of
|
||
> "candidate routines".
|
||
>
|
||
> 5. If you have more than one routine left, eliminate some routines
|
||
> according to type precedence rules. (We do some form of this, SQL99
|
||
> specifies something different.) This yields the set of "candidate subject
|
||
> routines".
|
||
>
|
||
> 6. Choose the routine whose schema is earliest in the path as the "subject
|
||
> routine".
|
||
>
|
||
> Execute the subject routine. Phew!
|
||
>
|
||
> This doesn't look glaringly wrong to me, so maybe you want to consider it.
|
||
> Please note step 2.
|
||
>
|
||
> --
|
||
> Peter Eisentraut peter_e@gmx.net
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 2: you can get off all lists at once with the unregister command
|
||
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
|
||
|
||
From pgsql-hackers-owner+M18249=candle.pha.pa.us=pgman@postgresql.org Mon Jan 28 19:34:59 2002
|
||
Return-path: <pgsql-hackers-owner+M18249=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0T0Ywe04781
|
||
for <pgman@candle.pha.pa.us>; Mon, 28 Jan 2002 19:34:58 -0500 (EST)
|
||
Received: (qmail 99270 invoked by alias); 29 Jan 2002 00:34:49 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 29 Jan 2002 00:34:49 -0000
|
||
Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0T0WDl98697
|
||
for <pgsql-hackers@postgreSQL.org>; Mon, 28 Jan 2002 19:32:13 -0500 (EST)
|
||
(envelope-from wrstuden@netbsd.org)
|
||
Received: (qmail 26513 invoked by uid 1130); 29 Jan 2002 00:31:57 -0000
|
||
Date: Mon, 28 Jan 2002 16:27:04 -0800 (PST)
|
||
From: Bill Studenmund <wrstuden@netbsd.org>
|
||
X-X-Sender: <wrstuden@vespasia.home-net.internetconnect.net>
|
||
To: Hiroshi Inoue <Inoue@tpf.co.jp>
|
||
cc: Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>,
|
||
Stephan Szabo <sszabo@megazone23.bigpanda.com>,
|
||
PostgreSQL Development <pgsql-hackers@postgresql.org>,
|
||
Fernando Nasser <fnasser@redhat.com>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <3C54AA51.64CE68AD@tpf.co.jp>
|
||
Message-ID: <Pine.NEB.4.33.0201281624010.18868-100000@vespasia.home-net.internetconnect.net>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Mon, 28 Jan 2002, Hiroshi Inoue wrote:
|
||
|
||
> Is *the path* below the same as "search path* in other
|
||
> postings about this thread ?
|
||
|
||
I think so. I believe the path I've been talking about is the one in step
|
||
6 below.
|
||
|
||
Take care,
|
||
|
||
Bill
|
||
|
||
> Maybe Peter's posting isn't the one exactly what I have to
|
||
> ask but there are too many postings for me to follow.
|
||
>
|
||
> regards,
|
||
> Hiroshi Inoue
|
||
>
|
||
> Peter Eisentraut wrote:
|
||
> >
|
||
> > Bill Studenmund writes:
|
||
> >
|
||
> > > Does SQL'99 say anything about this?
|
||
> >
|
||
> > Yes, though, as usual, you have to twist your brain a little to understand
|
||
> > it. My understanding is that for a function call of the form "foo(a, b)"
|
||
> > it goes like this:
|
||
> >
|
||
> > 1. Find all functions named "foo" in the current database. This is the
|
||
> > set of "possibly candidate routines".
|
||
> >
|
||
> > 2. Drop all routines that you do not have EXECUTE privilege for. This is
|
||
> > the set of "executable routines".
|
||
> >
|
||
> > 3. Drop all routines that do not have compatible parameter lists. This is
|
||
> > the set of "invocable routines".
|
||
> >
|
||
> > 4. Drop all routines whose schema is not in the path. This is the set of
|
||
> > "candidate routines".
|
||
> >
|
||
> > 5. If you have more than one routine left, eliminate some routines
|
||
> > according to type precedence rules. (We do some form of this, SQL99
|
||
> > specifies something different.) This yields the set of "candidate subject
|
||
> > routines".
|
||
> >
|
||
> > 6. Choose the routine whose schema is earliest in the path as the "subject
|
||
> > routine".
|
||
> >
|
||
> > Execute the subject routine. Phew!
|
||
> >
|
||
> > This doesn't look glaringly wrong to me, so maybe you want to consider it.
|
||
> > Please note step 2.
|
||
> >
|
||
> > --
|
||
> > Peter Eisentraut peter_e@gmx.net
|
||
>
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 4: Don't 'kill -9' the postmaster
|
||
|
||
From pgsql-hackers-owner+M18257=candle.pha.pa.us=pgman@postgresql.org Tue Jan 29 01:14:41 2002
|
||
Return-path: <pgsql-hackers-owner+M18257=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0T6Eee16404
|
||
for <pgman@candle.pha.pa.us>; Tue, 29 Jan 2002 01:14:40 -0500 (EST)
|
||
Received: (qmail 64203 invoked by alias); 29 Jan 2002 06:14:43 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 29 Jan 2002 06:14:43 -0000
|
||
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0T5lJl60013
|
||
for <pgsql-hackers@postgreSQL.org>; Tue, 29 Jan 2002 00:47:20 -0500 (EST)
|
||
(envelope-from Inoue@tpf.co.jp)
|
||
Received: (qmail 19665 invoked from network); 29 Jan 2002 05:47:24 -0000
|
||
Received: from unknown (HELO viscomail.tpf.co.jp) (100.0.0.108)
|
||
by sd2.tpf-fw-c.co.jp with SMTP; 29 Jan 2002 05:47:24 -0000
|
||
Received: from tpf.co.jp (3dgateway1 [126.0.1.60])
|
||
by viscomail.tpf.co.jp (8.8.8+Sun/8.8.8) with ESMTP id OAA07250;
|
||
Tue, 29 Jan 2002 14:47:22 +0900 (JST)
|
||
Message-ID: <3C56376C.BCA5B3A5@tpf.co.jp>
|
||
Date: Tue, 29 Jan 2002 14:47:24 +0900
|
||
From: Hiroshi Inoue <Inoue@tpf.co.jp>
|
||
X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U)
|
||
X-Accept-Language: ja
|
||
MIME-Version: 1.0
|
||
To: Bill Studenmund <wrstuden@netbsd.org>
|
||
cc: Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>,
|
||
Stephan Szabo <sszabo@megazone23.bigpanda.com>,
|
||
PostgreSQL Development <pgsql-hackers@postgresql.org>,
|
||
Fernando Nasser <fnasser@redhat.com>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
References: <Pine.NEB.4.33.0201281624010.18868-100000@vespasia.home-net.internetconnect.net>
|
||
Content-Type: text/plain; charset=iso-2022-jp
|
||
Content-Transfer-Encoding: 7bit
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Bill Studenmund wrote:
|
||
>
|
||
> On Mon, 28 Jan 2002, Hiroshi Inoue wrote:
|
||
>
|
||
> > Is *the path* below the same as "search path* in other
|
||
> > postings about this thread ?
|
||
>
|
||
> I think so. I believe the path I've been talking about is the one in step
|
||
> 6 below.
|
||
|
||
What I can find in SQL99 is SQL-path.
|
||
Does *the path*(i.e search path) mean SQL-path ?
|
||
They don't seem the same to me.
|
||
|
||
regards,
|
||
Hiroshi Inoue
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 2: you can get off all lists at once with the unregister command
|
||
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
|
||
|
||
From pgsql-hackers-owner+M18271=candle.pha.pa.us=pgman@postgresql.org Tue Jan 29 12:55:04 2002
|
||
Return-path: <pgsql-hackers-owner+M18271=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0THt2P00626
|
||
for <pgman@candle.pha.pa.us>; Tue, 29 Jan 2002 12:55:02 -0500 (EST)
|
||
Received: (qmail 77793 invoked by alias); 29 Jan 2002 17:54:57 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 29 Jan 2002 17:54:57 -0000
|
||
Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0THmBl76965
|
||
for <pgsql-hackers@postgreSQL.org>; Tue, 29 Jan 2002 12:48:11 -0500 (EST)
|
||
(envelope-from wrstuden@netbsd.org)
|
||
Received: (qmail 23554 invoked by uid 1130); 29 Jan 2002 17:48:16 -0000
|
||
Date: Tue, 29 Jan 2002 09:43:22 -0800 (PST)
|
||
From: Bill Studenmund <wrstuden@netbsd.org>
|
||
X-X-Sender: <wrstuden@vespasia.home-net.internetconnect.net>
|
||
To: Hiroshi Inoue <Inoue@tpf.co.jp>
|
||
cc: Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>,
|
||
Stephan Szabo <sszabo@megazone23.bigpanda.com>,
|
||
PostgreSQL Development <pgsql-hackers@postgresql.org>,
|
||
Fernando Nasser <fnasser@redhat.com>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <3C56376C.BCA5B3A5@tpf.co.jp>
|
||
Message-ID: <Pine.NEB.4.33.0201290939350.24201-100000@vespasia.home-net.internetconnect.net>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Tue, 29 Jan 2002, Hiroshi Inoue wrote:
|
||
|
||
> Bill Studenmund wrote:
|
||
> >
|
||
> > On Mon, 28 Jan 2002, Hiroshi Inoue wrote:
|
||
> >
|
||
> > > Is *the path* below the same as "search path* in other
|
||
> > > postings about this thread ?
|
||
> >
|
||
> > I think so. I believe the path I've been talking about is the one in step
|
||
> > 6 below.
|
||
>
|
||
> What I can find in SQL99 is SQL-path.
|
||
> Does *the path*(i.e search path) mean SQL-path ?
|
||
> They don't seem the same to me.
|
||
|
||
While we may have not been using the terminology of the spec, I think we
|
||
have been talking about schema paths from SQL99.
|
||
|
||
One difference between our discussions and SQL99 I've noticed is that
|
||
we've spoken of having the path find functions (and operators and
|
||
aggregates), types, _and_tables_. SQL99 doesn't have tables in there
|
||
AFAICT, but I think it makes sense.
|
||
|
||
Take care,
|
||
|
||
Bill
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
|
||
|
||
From pgsql-hackers-owner+M18273=candle.pha.pa.us=pgman@postgresql.org Tue Jan 29 19:25:30 2002
|
||
Return-path: <pgsql-hackers-owner+M18273=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0U0PUP06467
|
||
for <pgman@candle.pha.pa.us>; Tue, 29 Jan 2002 19:25:30 -0500 (EST)
|
||
Received: (qmail 92158 invoked by alias); 30 Jan 2002 00:25:29 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 30 Jan 2002 00:25:29 -0000
|
||
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0U0Kil91336
|
||
for <pgsql-hackers@postgreSQL.org>; Tue, 29 Jan 2002 19:20:45 -0500 (EST)
|
||
(envelope-from Inoue@tpf.co.jp)
|
||
Received: (qmail 18978 invoked from network); 30 Jan 2002 00:20:46 -0000
|
||
Received: from unknown (HELO viscomail.tpf.co.jp) (100.0.0.108)
|
||
by sd2.tpf-fw-c.co.jp with SMTP; 30 Jan 2002 00:20:46 -0000
|
||
Received: from tpf.co.jp (3dgateway1 [126.0.1.60])
|
||
by viscomail.tpf.co.jp (8.8.8+Sun/8.8.8) with ESMTP id JAA08622;
|
||
Wed, 30 Jan 2002 09:20:44 +0900 (JST)
|
||
Message-ID: <3C573C5E.F01B48C2@tpf.co.jp>
|
||
Date: Wed, 30 Jan 2002 09:20:46 +0900
|
||
From: Hiroshi Inoue <Inoue@tpf.co.jp>
|
||
X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U)
|
||
X-Accept-Language: ja
|
||
MIME-Version: 1.0
|
||
To: Bill Studenmund <wrstuden@netbsd.org>, Peter Eisentraut <peter_e@gmx.net>,
|
||
Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
References: <Pine.NEB.4.33.0201290939350.24201-100000@vespasia.home-net.internetconnect.net>
|
||
Content-Type: text/plain; charset=iso-2022-jp
|
||
Content-Transfer-Encoding: 7bit
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Bill Studenmund wrote:
|
||
>
|
||
> On Tue, 29 Jan 2002, Hiroshi Inoue wrote:
|
||
>
|
||
> > What I can find in SQL99 is SQL-path.
|
||
> > Does *the path*(i.e search path) mean SQL-path ?
|
||
> > They don't seem the same to me.
|
||
>
|
||
> While we may have not been using the terminology of the spec, I think we
|
||
> have been talking about schema paths from SQL99.
|
||
>
|
||
> One difference between our discussions and SQL99 I've noticed is that
|
||
> we've spoken of having the path find functions (and operators and
|
||
> aggregates), types, _and_tables_.
|
||
|
||
My understanding is the same.
|
||
Tom, Peter is it right ?
|
||
|
||
> SQL99 doesn't have tables in there
|
||
> AFAICT, but I think it makes sense.
|
||
|
||
It seems to make sense but they are different and
|
||
our *path* is never an extension of SQL-path.
|
||
Where are the difference or the relevance referred
|
||
to in this thread ?
|
||
|
||
regards,
|
||
Hiroshi Inoue
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 6: Have you searched our list archives?
|
||
|
||
http://archives.postgresql.org
|
||
|
||
From pgsql-hackers-owner+M18305=candle.pha.pa.us=pgman@postgresql.org Wed Jan 30 15:15:26 2002
|
||
Return-path: <pgsql-hackers-owner+M18305=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0UKFOP11825
|
||
for <pgman@candle.pha.pa.us>; Wed, 30 Jan 2002 15:15:25 -0500 (EST)
|
||
Received: (qmail 72977 invoked by alias); 30 Jan 2002 20:15:22 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 30 Jan 2002 20:15:22 -0000
|
||
Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0UKEKl72120
|
||
for <pgsql-hackers@postgreSQL.org>; Wed, 30 Jan 2002 15:14:20 -0500 (EST)
|
||
(envelope-from wrstuden@netbsd.org)
|
||
Received: (qmail 23890 invoked by uid 1130); 30 Jan 2002 20:13:52 -0000
|
||
Date: Wed, 30 Jan 2002 12:08:54 -0800 (PST)
|
||
From: Bill Studenmund <wrstuden@netbsd.org>
|
||
X-X-Sender: <wrstuden@vespasia.home-net.internetconnect.net>
|
||
To: Hiroshi Inoue <Inoue@tpf.co.jp>
|
||
cc: Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>,
|
||
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <3C573C5E.F01B48C2@tpf.co.jp>
|
||
Message-ID: <Pine.NEB.4.33.0201301207540.26920-100000@vespasia.home-net.internetconnect.net>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Wed, 30 Jan 2002, Hiroshi Inoue wrote:
|
||
|
||
> Bill Studenmund wrote:
|
||
> >
|
||
> > On Tue, 29 Jan 2002, Hiroshi Inoue wrote:
|
||
> > SQL99 doesn't have tables in there
|
||
> > AFAICT, but I think it makes sense.
|
||
>
|
||
> It seems to make sense but they are different and
|
||
> our *path* is never an extension of SQL-path.
|
||
> Where are the difference or the relevance referred
|
||
> to in this thread ?
|
||
|
||
How is our path not an extention of SQL-path? Or at least how is the path
|
||
I've been pushing not an SQL-path?
|
||
|
||
Take care,
|
||
|
||
Bill
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 2: you can get off all lists at once with the unregister command
|
||
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
|
||
|
||
From pgsql-hackers-owner+M18307=candle.pha.pa.us=pgman@postgresql.org Wed Jan 30 16:15:23 2002
|
||
Return-path: <pgsql-hackers-owner+M18307=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0ULFMP19850
|
||
for <pgman@candle.pha.pa.us>; Wed, 30 Jan 2002 16:15:22 -0500 (EST)
|
||
Received: (qmail 96622 invoked by alias); 30 Jan 2002 21:15:08 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 30 Jan 2002 21:15:08 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0ULD4l95438
|
||
for <pgsql-hackers@postgresql.org>; Wed, 30 Jan 2002 16:13:04 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0ULCPf26128;
|
||
Wed, 30 Jan 2002 16:12:25 -0500 (EST)
|
||
To: Stephan Szabo <sszabo@megazone23.bigpanda.com>
|
||
cc: Bill Studenmund <wrstuden@netbsd.org>, Peter Eisentraut <peter_e@gmx.net>,
|
||
pgsql-hackers@postgresql.org, Fernando Nasser <fnasser@redhat.com>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <20020123162426.K22713-100000@megazone23.bigpanda.com>
|
||
References: <20020123162426.K22713-100000@megazone23.bigpanda.com>
|
||
Comments: In-reply-to Stephan Szabo <sszabo@megazone23.bigpanda.com>
|
||
message dated "Wed, 23 Jan 2002 16:34:32 -0800"
|
||
Date: Wed, 30 Jan 2002 16:12:24 -0500
|
||
Message-ID: <26125.1012425144@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
[ just catching up on this thread after a couple days thinking about
|
||
other things ]
|
||
|
||
Stephan Szabo <sszabo@megazone23.bigpanda.com> writes:
|
||
> AFAIK there's no way to specify that I want to make the function
|
||
> complex(integer) such that I can do CAST(1 as complex) but not as an
|
||
> implicit cast.
|
||
|
||
You may have forgotten that I recently suggested adding just such a
|
||
feature, ie a boolean flag on pg_proc rows to indicate whether they can
|
||
be considered for implicit casts. I think we'd agreed that it would be
|
||
a good thing to do in 7.3.
|
||
|
||
However, that doesn't bear very much on the general argument of the
|
||
thread. The bottom line is that we've put a whole lot of sweat into
|
||
developing rules for resolving ambiguous operator and function calls,
|
||
and I don't think we're going to be willing to toss all that effort into
|
||
the scrap heap. But making namespace search order the dominant factor
|
||
in choosing a function/operator (as Bill seems to want) would certainly
|
||
break all that carefully-crafted effort. If we put the system namespace
|
||
at the front of the search list then users would be unable to override
|
||
standard operators with schema-local substitutes; clearly that's no
|
||
good. But if we put it at the back, then a schema-local user operator
|
||
would dominate all system entries of the same operator name, even for
|
||
quite different types, and thereby it would break the resolution
|
||
behavior.
|
||
|
||
So I'm still of the opinion that my original suggestion is the only
|
||
workable one: collect candidates across all available namespaces,
|
||
discarding only those that are exact matches to candidates in earlier
|
||
namespaces, and then apply the existing resolution rules to the
|
||
collection. AFAICS this need not be any slower than what we do now,
|
||
if the catalog is set up so that we can collect candidates in one
|
||
indexscan without regard to namespace. The case where there actually
|
||
are any exact matches to discard should be uncommon, so we can deal with
|
||
it later on in the resolution process.
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 3: if posting/reading through Usenet, please send an appropriate
|
||
subscribe-nomail command to majordomo@postgresql.org so that your
|
||
message can get through to the mailing list cleanly
|
||
|
||
From pgsql-hackers-owner+M18308=candle.pha.pa.us=pgman@postgresql.org Wed Jan 30 16:25:39 2002
|
||
Return-path: <pgsql-hackers-owner+M18308=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0ULPcP20879
|
||
for <pgman@candle.pha.pa.us>; Wed, 30 Jan 2002 16:25:38 -0500 (EST)
|
||
Received: (qmail 3172 invoked by alias); 30 Jan 2002 21:25:37 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 30 Jan 2002 21:25:37 -0000
|
||
Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0ULM4l01963
|
||
for <pgsql-hackers@postgresql.org>; Wed, 30 Jan 2002 16:22:04 -0500 (EST)
|
||
(envelope-from wrstuden@netbsd.org)
|
||
Received: (qmail 21064 invoked by uid 1130); 30 Jan 2002 21:22:04 -0000
|
||
Date: Wed, 30 Jan 2002 13:17:07 -0800 (PST)
|
||
From: Bill Studenmund <wrstuden@netbsd.org>
|
||
X-X-Sender: <wrstuden@vespasia.home-net.internetconnect.net>
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Stephan Szabo <sszabo@megazone23.bigpanda.com>,
|
||
Peter Eisentraut <peter_e@gmx.net>, <pgsql-hackers@postgresql.org>,
|
||
Fernando Nasser <fnasser@redhat.com>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <26125.1012425144@sss.pgh.pa.us>
|
||
Message-ID: <Pine.NEB.4.33.0201301311020.26920-100000@vespasia.home-net.internetconnect.net>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Wed, 30 Jan 2002, Tom Lane wrote:
|
||
|
||
> [ just catching up on this thread after a couple days thinking about
|
||
> other things ]
|
||
>
|
||
> However, that doesn't bear very much on the general argument of the
|
||
> thread. The bottom line is that we've put a whole lot of sweat into
|
||
> developing rules for resolving ambiguous operator and function calls,
|
||
> and I don't think we're going to be willing to toss all that effort into
|
||
> the scrap heap. But making namespace search order the dominant factor
|
||
> in choosing a function/operator (as Bill seems to want) would certainly
|
||
> break all that carefully-crafted effort. If we put the system namespace
|
||
> at the front of the search list then users would be unable to override
|
||
> standard operators with schema-local substitutes; clearly that's no
|
||
> good. But if we put it at the back, then a schema-local user operator
|
||
> would dominate all system entries of the same operator name, even for
|
||
> quite different types, and thereby it would break the resolution
|
||
> behavior.
|
||
|
||
I've changed my mind. :-)
|
||
|
||
> So I'm still of the opinion that my original suggestion is the only
|
||
> workable one: collect candidates across all available namespaces,
|
||
> discarding only those that are exact matches to candidates in earlier
|
||
> namespaces, and then apply the existing resolution rules to the
|
||
> collection. AFAICS this need not be any slower than what we do now,
|
||
> if the catalog is set up so that we can collect candidates in one
|
||
> indexscan without regard to namespace. The case where there actually
|
||
> are any exact matches to discard should be uncommon, so we can deal with
|
||
> it later on in the resolution process.
|
||
|
||
Sounds like the thing to do, and it matches the spec. :-)
|
||
|
||
Oh, you can make a path with your namespace before the built-in one. It's
|
||
just that if you don't include the built-in one (IMPLIMENTATION_SCHEMA) in
|
||
a path, you're supposed to prepend it to the specified list.
|
||
|
||
Take care,
|
||
|
||
Bill
|
||
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 6: Have you searched our list archives?
|
||
|
||
http://archives.postgresql.org
|
||
|
||
From pgsql-hackers-owner+M18311=candle.pha.pa.us=pgman@postgresql.org Wed Jan 30 18:15:49 2002
|
||
Return-path: <pgsql-hackers-owner+M18311=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0UNFmP04299
|
||
for <pgman@candle.pha.pa.us>; Wed, 30 Jan 2002 18:15:48 -0500 (EST)
|
||
Received: (qmail 40895 invoked by alias); 30 Jan 2002 23:15:47 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 30 Jan 2002 23:15:47 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0UNDrl39795
|
||
for <pgsql-hackers@postgresql.org>; Wed, 30 Jan 2002 18:13:53 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0UND7f27530;
|
||
Wed, 30 Jan 2002 18:13:07 -0500 (EST)
|
||
To: Hiroshi Inoue <Inoue@tpf.co.jp>
|
||
cc: Bill Studenmund <wrstuden@netbsd.org>, Peter Eisentraut <peter_e@gmx.net>,
|
||
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <3C573C5E.F01B48C2@tpf.co.jp>
|
||
References: <Pine.NEB.4.33.0201290939350.24201-100000@vespasia.home-net.internetconnect.net> <3C573C5E.F01B48C2@tpf.co.jp>
|
||
Comments: In-reply-to Hiroshi Inoue <Inoue@tpf.co.jp>
|
||
message dated "Wed, 30 Jan 2002 09:20:46 +0900"
|
||
Date: Wed, 30 Jan 2002 18:13:06 -0500
|
||
Message-ID: <27527.1012432386@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Hiroshi Inoue <Inoue@tpf.co.jp> writes:
|
||
> Bill Studenmund wrote:
|
||
>> While we may have not been using the terminology of the spec, I think we
|
||
>> have been talking about schema paths from SQL99.
|
||
>>
|
||
>> One difference between our discussions and SQL99 I've noticed is that
|
||
>> we've spoken of having the path find functions (and operators and
|
||
>> aggregates), types, _and_tables_.
|
||
|
||
> My understanding is the same.
|
||
> Tom, Peter is it right ?
|
||
|
||
SQL99's SQL-path is very clearly stated to be used only for looking up
|
||
routines and user-defined type names. Extending it to cover tables,
|
||
operators, and so forth makes sense to me, but we have to recognize
|
||
that it is a spec extension and therefore not all the answers we need
|
||
can be found in the spec.
|
||
|
||
I also find it curious that they exclude standard type names from the
|
||
search path. It would seem obvious to treat the standard type names
|
||
as included in a schema that is part of the search path, but AFAICT
|
||
this is not done in the spec. Postgres *has to* do it that way,
|
||
however, or give up our whole approach to datatypes; surely we don't
|
||
want to hardwire the SQL-standard datatypes into the parser to the
|
||
exclusion of the not-so-standard ones.
|
||
|
||
IMHO, the spec's artificial distinction between system and user types
|
||
limits its usefulness as a guide to the questions we're debating here.
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 5: Have you checked our extensive FAQ?
|
||
|
||
http://www.postgresql.org/users-lounge/docs/faq.html
|
||
|
||
From pgsql-hackers-owner+M18312=candle.pha.pa.us=pgman@postgresql.org Wed Jan 30 18:55:30 2002
|
||
Return-path: <pgsql-hackers-owner+M18312=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0UNtSP08482
|
||
for <pgman@candle.pha.pa.us>; Wed, 30 Jan 2002 18:55:29 -0500 (EST)
|
||
Received: (qmail 58399 invoked by alias); 30 Jan 2002 23:55:26 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 30 Jan 2002 23:55:26 -0000
|
||
Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0UNqhl56957
|
||
for <pgsql-hackers@postgresql.org>; Wed, 30 Jan 2002 18:52:43 -0500 (EST)
|
||
(envelope-from wrstuden@netbsd.org)
|
||
Received: (qmail 17164 invoked by uid 1130); 30 Jan 2002 23:46:06 -0000
|
||
Date: Wed, 30 Jan 2002 15:41:09 -0800 (PST)
|
||
From: Bill Studenmund <wrstuden@netbsd.org>
|
||
X-X-Sender: <wrstuden@vespasia.home-net.internetconnect.net>
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Hiroshi Inoue <Inoue@tpf.co.jp>, Peter Eisentraut <peter_e@gmx.net>,
|
||
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <27527.1012432386@sss.pgh.pa.us>
|
||
Message-ID: <Pine.NEB.4.33.0201301529010.26920-100000@vespasia.home-net.internetconnect.net>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Wed, 30 Jan 2002, Tom Lane wrote:
|
||
|
||
> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
|
||
> > Bill Studenmund wrote:
|
||
> >> While we may have not been using the terminology of the spec, I think we
|
||
> >> have been talking about schema paths from SQL99.
|
||
> >>
|
||
> >> One difference between our discussions and SQL99 I've noticed is that
|
||
> >> we've spoken of having the path find functions (and operators and
|
||
> >> aggregates), types, _and_tables_.
|
||
>
|
||
> > My understanding is the same.
|
||
> > Tom, Peter is it right ?
|
||
>
|
||
> SQL99's SQL-path is very clearly stated to be used only for looking up
|
||
> routines and user-defined type names. Extending it to cover tables,
|
||
> operators, and so forth makes sense to me, but we have to recognize
|
||
> that it is a spec extension and therefore not all the answers we need
|
||
> can be found in the spec.
|
||
|
||
True. I think that extending the path to be used for operators and
|
||
aggregates makes sense as they are special types of function calls. The
|
||
searching for tables might need to be a configurable parameter (defaulting
|
||
to yes), though. I think it makes sense to do, but I can imagine cases
|
||
where apps need to not.
|
||
|
||
> I also find it curious that they exclude standard type names from the
|
||
> search path. It would seem obvious to treat the standard type names
|
||
> as included in a schema that is part of the search path, but AFAICT
|
||
> this is not done in the spec. Postgres *has to* do it that way,
|
||
> however, or give up our whole approach to datatypes; surely we don't
|
||
> want to hardwire the SQL-standard datatypes into the parser to the
|
||
> exclusion of the not-so-standard ones.
|
||
>
|
||
> IMHO, the spec's artificial distinction between system and user types
|
||
> limits its usefulness as a guide to the questions we're debating here.
|
||
|
||
True.
|
||
|
||
Does SQL99 support types as flexable as the ones we do? I know types in
|
||
Oracle are basically special cases of already built-in ones...
|
||
|
||
Take care,
|
||
|
||
Bill
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 2: you can get off all lists at once with the unregister command
|
||
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
|
||
|
||
From pgsql-hackers-owner+M18314=candle.pha.pa.us=pgman@postgresql.org Wed Jan 30 19:15:14 2002
|
||
Return-path: <pgsql-hackers-owner+M18314=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0V0FDP11130
|
||
for <pgman@candle.pha.pa.us>; Wed, 30 Jan 2002 19:15:14 -0500 (EST)
|
||
Received: (qmail 70218 invoked by alias); 31 Jan 2002 00:15:12 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 31 Jan 2002 00:15:12 -0000
|
||
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0UNtQl58401
|
||
for <pgsql-hackers@postgreSQL.org>; Wed, 30 Jan 2002 18:55:28 -0500 (EST)
|
||
(envelope-from Inoue@tpf.co.jp)
|
||
Received: (qmail 11171 invoked from network); 30 Jan 2002 23:55:24 -0000
|
||
Received: from unknown (HELO viscomail.tpf.co.jp) (100.0.0.108)
|
||
by sd2.tpf-fw-c.co.jp with SMTP; 30 Jan 2002 23:55:24 -0000
|
||
Received: from tpf.co.jp (3dgateway1 [126.0.1.60])
|
||
by viscomail.tpf.co.jp (8.8.8+Sun/8.8.8) with ESMTP id IAA10232;
|
||
Thu, 31 Jan 2002 08:55:17 +0900 (JST)
|
||
Message-ID: <3C5887E8.CE7E569F@tpf.co.jp>
|
||
Date: Thu, 31 Jan 2002 08:55:20 +0900
|
||
From: Hiroshi Inoue <Inoue@tpf.co.jp>
|
||
X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U)
|
||
X-Accept-Language: ja
|
||
MIME-Version: 1.0
|
||
To: Bill Studenmund <wrstuden@netbsd.org>
|
||
cc: Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>,
|
||
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
References: <Pine.NEB.4.33.0201301207540.26920-100000@vespasia.home-net.internetconnect.net>
|
||
Content-Type: text/plain; charset=iso-2022-jp
|
||
Content-Transfer-Encoding: 7bit
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Bill Studenmund wrote:
|
||
>
|
||
> On Wed, 30 Jan 2002, Hiroshi Inoue wrote:
|
||
>
|
||
> > Bill Studenmund wrote:
|
||
> > >
|
||
> > > On Tue, 29 Jan 2002, Hiroshi Inoue wrote:
|
||
> > > SQL99 doesn't have tables in there
|
||
> > > AFAICT, but I think it makes sense.
|
||
> >
|
||
> > It seems to make sense but they are different and
|
||
> > our *path* is never an extension of SQL-path.
|
||
> > Where are the difference or the relevance referred
|
||
> > to in this thread ?
|
||
>
|
||
> How is our path not an extention of SQL-path? Or at least how is the path
|
||
> I've been pushing not an SQL-path?
|
||
|
||
IMHO _tables_like objects must be guarded from such
|
||
a search mechanism fundamentally. I don't object to
|
||
the use of our *path* but it should be distinguished
|
||
from SQL-path.
|
||
|
||
For example the PATH environment variable is used
|
||
only to search executables not files. Is it
|
||
preferable for *rm a_file* to search all the directory
|
||
in the PATH ? If the purpose is different the different
|
||
*path* is needed of cource.
|
||
|
||
regards,
|
||
Hiroshi Inoue
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 2: you can get off all lists at once with the unregister command
|
||
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
|
||
|
||
From pgsql-hackers-owner+M18317=candle.pha.pa.us=pgman@postgresql.org Wed Jan 30 21:15:26 2002
|
||
Return-path: <pgsql-hackers-owner+M18317=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0V2FPP23342
|
||
for <pgman@candle.pha.pa.us>; Wed, 30 Jan 2002 21:15:25 -0500 (EST)
|
||
Received: (qmail 15445 invoked by alias); 31 Jan 2002 02:15:12 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 31 Jan 2002 02:15:12 -0000
|
||
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0V1v1l07129
|
||
for <pgsql-hackers@postgresql.org>; Wed, 30 Jan 2002 20:57:01 -0500 (EST)
|
||
(envelope-from Inoue@tpf.co.jp)
|
||
Received: (qmail 21526 invoked from network); 31 Jan 2002 01:57:03 -0000
|
||
Received: from unknown (HELO viscomail.tpf.co.jp) (100.0.0.108)
|
||
by sd2.tpf-fw-c.co.jp with SMTP; 31 Jan 2002 01:57:03 -0000
|
||
Received: from tpf.co.jp (3dgateway1 [126.0.1.60])
|
||
by viscomail.tpf.co.jp (8.8.8+Sun/8.8.8) with ESMTP id KAA10366;
|
||
Thu, 31 Jan 2002 10:57:02 +0900 (JST)
|
||
Message-ID: <3C58A472.2E90C21C@tpf.co.jp>
|
||
Date: Thu, 31 Jan 2002 10:57:06 +0900
|
||
From: Hiroshi Inoue <Inoue@tpf.co.jp>
|
||
X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U)
|
||
X-Accept-Language: ja
|
||
MIME-Version: 1.0
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Bill Studenmund <wrstuden@netbsd.org>, Peter Eisentraut <peter_e@gmx.net>,
|
||
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
References: <Pine.NEB.4.33.0201290939350.24201-100000@vespasia.home-net.internetconnect.net> <3C573C5E.F01B48C2@tpf.co.jp> <27527.1012432386@sss.pgh.pa.us>
|
||
Content-Type: text/plain; charset=iso-2022-jp
|
||
Content-Transfer-Encoding: 7bit
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Tom Lane wrote:
|
||
>
|
||
> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
|
||
> > Bill Studenmund wrote:
|
||
> >> While we may have not been using the terminology of the spec, I think we
|
||
> >> have been talking about schema paths from SQL99.
|
||
> >>
|
||
> >> One difference between our discussions and SQL99 I've noticed is that
|
||
> >> we've spoken of having the path find functions (and operators and
|
||
> >> aggregates), types, _and_tables_.
|
||
>
|
||
> > My understanding is the same.
|
||
> > Tom, Peter is it right ?
|
||
>
|
||
> SQL99's SQL-path is very clearly stated to be used only for looking up
|
||
> routines and user-defined type names. Extending it to cover tables,
|
||
> operators, and so forth makes sense to me,
|
||
|
||
I have no objection to the point it makes sense to use
|
||
such *path*s internally but I think it also has a siginificance
|
||
for SQL-path to not look up _tables_like objects.
|
||
I think they are different from the first and we should(need)
|
||
not manage the system with one *path*.
|
||
|
||
BTW I see few references to *catalog*. Would the concept
|
||
of catalog be introduced together. If so what would be
|
||
contained in the current database.
|
||
|
||
regards,
|
||
Hiroshi Inoue
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 2: you can get off all lists at once with the unregister command
|
||
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
|
||
|
||
From pgsql-hackers-owner+M18319=candle.pha.pa.us=pgman@postgresql.org Wed Jan 30 21:45:37 2002
|
||
Return-path: <pgsql-hackers-owner+M18319=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0V2jZP27049
|
||
for <pgman@candle.pha.pa.us>; Wed, 30 Jan 2002 21:45:36 -0500 (EST)
|
||
Received: (qmail 27626 invoked by alias); 31 Jan 2002 02:45:32 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 31 Jan 2002 02:45:32 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0V2Wfl22316
|
||
for <pgsql-hackers@postgresql.org>; Wed, 30 Jan 2002 21:32:41 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0V2WAf29271;
|
||
Wed, 30 Jan 2002 21:32:10 -0500 (EST)
|
||
To: Hiroshi Inoue <Inoue@tpf.co.jp>
|
||
cc: Bill Studenmund <wrstuden@netbsd.org>, Peter Eisentraut <peter_e@gmx.net>,
|
||
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <3C58A472.2E90C21C@tpf.co.jp>
|
||
References: <Pine.NEB.4.33.0201290939350.24201-100000@vespasia.home-net.internetconnect.net> <3C573C5E.F01B48C2@tpf.co.jp> <27527.1012432386@sss.pgh.pa.us> <3C58A472.2E90C21C@tpf.co.jp>
|
||
Comments: In-reply-to Hiroshi Inoue <Inoue@tpf.co.jp>
|
||
message dated "Thu, 31 Jan 2002 10:57:06 +0900"
|
||
Date: Wed, 30 Jan 2002 21:32:10 -0500
|
||
Message-ID: <29268.1012444330@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Hiroshi Inoue <Inoue@tpf.co.jp> writes:
|
||
> I have no objection to the point it makes sense to use
|
||
> such *path*s internally but I think it also has a siginificance
|
||
> for SQL-path to not look up _tables_like objects.
|
||
> I think they are different from the first and we should(need)
|
||
> not manage the system with one *path*.
|
||
|
||
I'm unconvinced. We must search for datatypes and tables on the same
|
||
path because tables have associated datatypes; it will definitely not
|
||
do to look for a table's datatype and get the wrong type. And I think
|
||
that functions and operators should be looked for on the same path
|
||
as datatypes, because a type should be pretty closely associated with
|
||
the functions/operators for it. So it seems to me that the apparent
|
||
flexibility of having more than one path is just a way to shoot yourself
|
||
in the foot. Why are you concerned that we keep them separate?
|
||
|
||
> BTW I see few references to *catalog*. Would the concept
|
||
> of catalog be introduced together. If so what would be
|
||
> contained in the current database.
|
||
|
||
My thought is that we will consider catalog == database. As far as
|
||
I can tell, that is a legitimate implementation-defined way of
|
||
interpreting the spec. (It's not clear to me what the value is of
|
||
having more than one level of schema hierarchy; or at least, if you want
|
||
hierarchical namespaces, there's no argument for stopping at depth two.
|
||
But I digress.) To satisfy the spec we must allow a (purely decorative)
|
||
specification of the current database name as the catalog level of a
|
||
qualified name, but that's as far as I want to go. In this round,
|
||
anyway. Cross-database access is not something to tackle for 7.3.
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 2: you can get off all lists at once with the unregister command
|
||
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
|
||
|
||
From pgsql-hackers-owner+M18323=candle.pha.pa.us=pgman@postgresql.org Wed Jan 30 22:45:10 2002
|
||
Return-path: <pgsql-hackers-owner+M18323=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0V3j9P04896
|
||
for <pgman@candle.pha.pa.us>; Wed, 30 Jan 2002 22:45:09 -0500 (EST)
|
||
Received: (qmail 48073 invoked by alias); 31 Jan 2002 03:45:06 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 31 Jan 2002 03:45:06 -0000
|
||
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0V3aPl45009
|
||
for <pgsql-hackers@postgresql.org>; Wed, 30 Jan 2002 22:36:27 -0500 (EST)
|
||
(envelope-from Inoue@tpf.co.jp)
|
||
Received: (qmail 31045 invoked from network); 31 Jan 2002 03:36:21 -0000
|
||
Received: from unknown (HELO viscomail.tpf.co.jp) (100.0.0.108)
|
||
by sd2.tpf-fw-c.co.jp with SMTP; 31 Jan 2002 03:36:21 -0000
|
||
Received: from tpf.co.jp (3dgateway1 [126.0.1.60])
|
||
by viscomail.tpf.co.jp (8.8.8+Sun/8.8.8) with ESMTP id MAA10485;
|
||
Thu, 31 Jan 2002 12:36:15 +0900 (JST)
|
||
Message-ID: <3C58BBB3.58D5F964@tpf.co.jp>
|
||
Date: Thu, 31 Jan 2002 12:36:19 +0900
|
||
From: Hiroshi Inoue <Inoue@tpf.co.jp>
|
||
X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U)
|
||
X-Accept-Language: ja
|
||
MIME-Version: 1.0
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Bill Studenmund <wrstuden@netbsd.org>, Peter Eisentraut <peter_e@gmx.net>,
|
||
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
References: <Pine.NEB.4.33.0201290939350.24201-100000@vespasia.home-net.internetconnect.net> <3C573C5E.F01B48C2@tpf.co.jp> <27527.1012432386@sss.pgh.pa.us> <3C58A472.2E90C21C@tpf.co.jp> <29268.1012444330@sss.pgh.pa.us>
|
||
Content-Type: text/plain; charset=iso-2022-jp
|
||
Content-Transfer-Encoding: 7bit
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Tom Lane wrote:
|
||
>
|
||
> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
|
||
> > I have no objection to the point it makes sense to use
|
||
> > such *path*s internally but I think it also has a siginificance
|
||
> > for SQL-path to not look up _tables_like objects.
|
||
> > I think they are different from the first and we should(need)
|
||
> > not manage the system with one *path*.
|
||
>
|
||
> I'm unconvinced. We must search for datatypes and tables on the same
|
||
> path because tables have associated datatypes;
|
||
|
||
Isn't the table definition a part of the datatype in
|
||
such a case ?
|
||
|
||
> it will definitely not
|
||
> do to look for a table's datatype and get the wrong type. And I think
|
||
> that functions and operators should be looked for on the same path
|
||
> as datatypes, because a type should be pretty closely associated with
|
||
> the functions/operators for it. So it seems to me that the apparent
|
||
> flexibility of having more than one path is just a way to shoot yourself
|
||
> in the foot. Why are you concerned that we keep them separate?
|
||
|
||
For example, doesn't 'DROP table a_table' drop the
|
||
a_table table in a schema in the *path* if there's
|
||
no a_table table in the current schema ?
|
||
|
||
If we would never introduce SQL-paths (in the future)
|
||
there would be problem.
|
||
|
||
regards,
|
||
Hiroshi Inoue
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 2: you can get off all lists at once with the unregister command
|
||
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
|
||
|
||
From pgsql-hackers-owner+M18325=candle.pha.pa.us=pgman@postgresql.org Wed Jan 30 22:55:24 2002
|
||
Return-path: <pgsql-hackers-owner+M18325=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0V3tOP06352
|
||
for <pgman@candle.pha.pa.us>; Wed, 30 Jan 2002 22:55:24 -0500 (EST)
|
||
Received: (qmail 52777 invoked by alias); 31 Jan 2002 03:55:21 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 31 Jan 2002 03:55:21 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0V3iml47386
|
||
for <pgsql-hackers@postgresql.org>; Wed, 30 Jan 2002 22:44:48 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0V3hff29736;
|
||
Wed, 30 Jan 2002 22:43:42 -0500 (EST)
|
||
To: Hiroshi Inoue <Inoue@tpf.co.jp>
|
||
cc: Bill Studenmund <wrstuden@netbsd.org>, Peter Eisentraut <peter_e@gmx.net>,
|
||
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <3C58BBB3.58D5F964@tpf.co.jp>
|
||
References: <Pine.NEB.4.33.0201290939350.24201-100000@vespasia.home-net.internetconnect.net> <3C573C5E.F01B48C2@tpf.co.jp> <27527.1012432386@sss.pgh.pa.us> <3C58A472.2E90C21C@tpf.co.jp> <29268.1012444330@sss.pgh.pa.us> <3C58BBB3.58D5F964@tpf.co.jp>
|
||
Comments: In-reply-to Hiroshi Inoue <Inoue@tpf.co.jp>
|
||
message dated "Thu, 31 Jan 2002 12:36:19 +0900"
|
||
Date: Wed, 30 Jan 2002 22:43:41 -0500
|
||
Message-ID: <29733.1012448621@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Hiroshi Inoue <Inoue@tpf.co.jp> writes:
|
||
> For example, doesn't 'DROP table a_table' drop the
|
||
> a_table table in a schema in the *path* if there's
|
||
> no a_table table in the current schema ?
|
||
|
||
Sure. And that's exactly what it should do, IMHO.
|
||
Otherwise the notion that you can ignore your private
|
||
schema (at the front of the path) if you're not using
|
||
it falls down. Also, we wouldn't be able to implement
|
||
temp tables via a backend-local schema at the front of
|
||
the path.
|
||
|
||
Any security concerns here should be addressed by putting
|
||
ACLs on the schemas you don't want altered; not by contorting
|
||
the notion of a search path to work for some operations and
|
||
not others.
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 4: Don't 'kill -9' the postmaster
|
||
|
||
From pgsql-hackers-owner+M18326=candle.pha.pa.us=pgman@postgresql.org Wed Jan 30 23:15:07 2002
|
||
Return-path: <pgsql-hackers-owner+M18326=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0V4F6P09920
|
||
for <pgman@candle.pha.pa.us>; Wed, 30 Jan 2002 23:15:06 -0500 (EST)
|
||
Received: (qmail 57935 invoked by alias); 31 Jan 2002 04:15:03 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 31 Jan 2002 04:15:03 -0000
|
||
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0V3lIl50338
|
||
for <pgsql-hackers@postgresql.org>; Wed, 30 Jan 2002 22:47:20 -0500 (EST)
|
||
(envelope-from Inoue@tpf.co.jp)
|
||
Received: (qmail 31967 invoked from network); 31 Jan 2002 03:47:17 -0000
|
||
Received: from unknown (HELO viscomail.tpf.co.jp) (100.0.0.108)
|
||
by sd2.tpf-fw-c.co.jp with SMTP; 31 Jan 2002 03:47:17 -0000
|
||
Received: from tpf.co.jp (3dgateway1 [126.0.1.60])
|
||
by viscomail.tpf.co.jp (8.8.8+Sun/8.8.8) with ESMTP id MAA10500;
|
||
Thu, 31 Jan 2002 12:47:17 +0900 (JST)
|
||
Message-ID: <3C58BE48.AD4EE527@tpf.co.jp>
|
||
Date: Thu, 31 Jan 2002 12:47:20 +0900
|
||
From: Hiroshi Inoue <Inoue@tpf.co.jp>
|
||
X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U)
|
||
X-Accept-Language: ja
|
||
MIME-Version: 1.0
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Bill Studenmund <wrstuden@netbsd.org>, Peter Eisentraut <peter_e@gmx.net>,
|
||
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
References: <Pine.NEB.4.33.0201290939350.24201-100000@vespasia.home-net.internetconnect.net> <3C573C5E.F01B48C2@tpf.co.jp> <27527.1012432386@sss.pgh.pa.us> <3C58A472.2E90C21C@tpf.co.jp> <29268.1012444330@sss.pgh.pa.us>
|
||
Content-Type: text/plain; charset=iso-2022-jp
|
||
Content-Transfer-Encoding: 7bit
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Tom Lane wrote:
|
||
>
|
||
> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
|
||
>
|
||
> > BTW I see few references to *catalog*. Would the concept
|
||
> > of catalog be introduced together. If so what would be
|
||
> > contained in the current database.
|
||
>
|
||
> My thought is that we will consider catalog == database. As far as
|
||
> I can tell, that is a legitimate implementation-defined way of
|
||
> interpreting the spec. (It's not clear to me what the value is of
|
||
> having more than one level of schema hierarchy; or at least, if you want
|
||
> hierarchical namespaces, there's no argument for stopping at depth two.
|
||
> But I digress.) To satisfy the spec we must allow a (purely decorative)
|
||
> specification of the current database name as the catalog level of a
|
||
> qualified name, but that's as far as I want to go. In this round,
|
||
> anyway. Cross-database access is not something to tackle for 7.3.
|
||
|
||
Just a confirmation.
|
||
We can't see any catalog.schema.object notation in 7.3,
|
||
can we ?
|
||
|
||
regards,
|
||
Hiroshi Inoue
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 6: Have you searched our list archives?
|
||
|
||
http://archives.postgresql.org
|
||
|
||
From pgsql-hackers-owner+M18324=candle.pha.pa.us=pgman@postgresql.org Wed Jan 30 22:55:24 2002
|
||
Return-path: <pgsql-hackers-owner+M18324=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0V3tOP06351
|
||
for <pgman@candle.pha.pa.us>; Wed, 30 Jan 2002 22:55:24 -0500 (EST)
|
||
Received: (qmail 52747 invoked by alias); 31 Jan 2002 03:55:20 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 31 Jan 2002 03:55:20 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0V3pTl51655
|
||
for <pgsql-hackers@postgresql.org>; Wed, 30 Jan 2002 22:51:29 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0V3p0f29810;
|
||
Wed, 30 Jan 2002 22:51:00 -0500 (EST)
|
||
To: Hiroshi Inoue <Inoue@tpf.co.jp>
|
||
cc: Bill Studenmund <wrstuden@netbsd.org>, Peter Eisentraut <peter_e@gmx.net>,
|
||
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <3C58BE48.AD4EE527@tpf.co.jp>
|
||
References: <Pine.NEB.4.33.0201290939350.24201-100000@vespasia.home-net.internetconnect.net> <3C573C5E.F01B48C2@tpf.co.jp> <27527.1012432386@sss.pgh.pa.us> <3C58A472.2E90C21C@tpf.co.jp> <29268.1012444330@sss.pgh.pa.us> <3C58BE48.AD4EE527@tpf.co.jp>
|
||
Comments: In-reply-to Hiroshi Inoue <Inoue@tpf.co.jp>
|
||
message dated "Thu, 31 Jan 2002 12:47:20 +0900"
|
||
Date: Wed, 30 Jan 2002 22:51:00 -0500
|
||
Message-ID: <29807.1012449060@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Hiroshi Inoue <Inoue@tpf.co.jp> writes:
|
||
> Just a confirmation.
|
||
> We can't see any catalog.schema.object notation in 7.3,
|
||
> can we ?
|
||
|
||
No, what I meant was you could write catalog.schema.object --- but for
|
||
7.3, the system will only accept it if the catalog name is the same as
|
||
the current database. This satisfies the minimum requirements of the
|
||
spec, and it leaves notational room to use the catalog name as the cue
|
||
for cross-database access, if we ever decide we want to try to do that.
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 4: Don't 'kill -9' the postmaster
|
||
|
||
From pgsql-hackers-owner+M18334=candle.pha.pa.us=pgman@postgresql.org Thu Jan 31 05:45:28 2002
|
||
Return-path: <pgsql-hackers-owner+M18334=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0VAjRP11000
|
||
for <pgman@candle.pha.pa.us>; Thu, 31 Jan 2002 05:45:27 -0500 (EST)
|
||
Received: (qmail 4065 invoked by alias); 31 Jan 2002 10:45:25 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 31 Jan 2002 10:45:25 -0000
|
||
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0VAbGl02141
|
||
for <pgsql-hackers@postgresql.org>; Thu, 31 Jan 2002 05:37:17 -0500 (EST)
|
||
(envelope-from Inoue@tpf.co.jp)
|
||
Received: (qmail 30401 invoked from network); 31 Jan 2002 10:37:17 -0000
|
||
Received: from unknown (HELO viscomail.tpf.co.jp) (100.0.0.108)
|
||
by sd2.tpf-fw-c.co.jp with SMTP; 31 Jan 2002 10:37:17 -0000
|
||
Received: from tpf.co.jp (3dgateway1 [126.0.1.60])
|
||
by viscomail.tpf.co.jp (8.8.8+Sun/8.8.8) with ESMTP id TAA10891;
|
||
Thu, 31 Jan 2002 19:37:15 +0900 (JST)
|
||
Message-ID: <3C591E5E.14549DF@tpf.co.jp>
|
||
Date: Thu, 31 Jan 2002 19:37:18 +0900
|
||
From: Hiroshi Inoue <Inoue@tpf.co.jp>
|
||
X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U)
|
||
X-Accept-Language: ja
|
||
MIME-Version: 1.0
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Bill Studenmund <wrstuden@netbsd.org>, Peter Eisentraut <peter_e@gmx.net>,
|
||
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
References: <Pine.NEB.4.33.0201290939350.24201-100000@vespasia.home-net.internetconnect.net> <3C573C5E.F01B48C2@tpf.co.jp> <27527.1012432386@sss.pgh.pa.us> <3C58A472.2E90C21C@tpf.co.jp> <29268.1012444330@sss.pgh.pa.us> <3C58BBB3.58D5F964@tpf.co.jp> <29733.1012448621@sss.pgh.pa.us>
|
||
Content-Type: text/plain; charset=iso-2022-jp
|
||
Content-Transfer-Encoding: 7bit
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Tom Lane wrote:
|
||
>
|
||
> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
|
||
> > For example, doesn't 'DROP table a_table' drop the
|
||
> > a_table table in a schema in the *path* if there's
|
||
> > no a_table table in the current schema ?
|
||
>
|
||
> Sure. And that's exactly what it should do, IMHO.
|
||
> Otherwise the notion that you can ignore your private
|
||
> schema (at the front of the path) if you're not using
|
||
> it falls down. Also, we wouldn't be able to implement
|
||
> temp tables via a backend-local schema at the front of
|
||
> the path.
|
||
|
||
I don't think it's useful for tables other than temp
|
||
ones and I wouldn't use it other than for temp ones.
|
||
|
||
When we type 'rm a_file' in a shell environment
|
||
does the *rm* command search the PATH in finding
|
||
the a_file file ? Even though we need to implement
|
||
such a search mechanism we would use another path
|
||
different from the executable search PATH. I don't
|
||
think our *path* is an extension of SQL-path.
|
||
|
||
I wouldn't complain unless we call the *path*
|
||
as SQL-path or an extension of SQL-path.
|
||
|
||
regards,
|
||
Hiroshi Inoue
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 4: Don't 'kill -9' the postmaster
|
||
|
||
From pgsql-hackers-owner+M18340=candle.pha.pa.us=pgman@postgresql.org Thu Jan 31 11:55:49 2002
|
||
Return-path: <pgsql-hackers-owner+M18340=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0VGtmP13664
|
||
for <pgman@candle.pha.pa.us>; Thu, 31 Jan 2002 11:55:48 -0500 (EST)
|
||
Received: (qmail 32205 invoked by alias); 31 Jan 2002 16:53:46 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 31 Jan 2002 16:53:46 -0000
|
||
Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0VGVXl24649
|
||
for <pgsql-hackers@postgresql.org>; Thu, 31 Jan 2002 11:31:37 -0500 (EST)
|
||
(envelope-from wrstuden@netbsd.org)
|
||
Received: (qmail 29829 invoked by uid 1130); 31 Jan 2002 16:31:38 -0000
|
||
Date: Thu, 31 Jan 2002 08:26:40 -0800 (PST)
|
||
From: Bill Studenmund <wrstuden@netbsd.org>
|
||
X-X-Sender: <wrstuden@vespasia.home-net.internetconnect.net>
|
||
To: Hiroshi Inoue <Inoue@tpf.co.jp>
|
||
cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
|
||
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <3C58A472.2E90C21C@tpf.co.jp>
|
||
Message-ID: <Pine.NEB.4.33.0201310823050.29090-100000@vespasia.home-net.internetconnect.net>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Thu, 31 Jan 2002, Hiroshi Inoue wrote:
|
||
|
||
> Tom Lane wrote:
|
||
> >
|
||
> > Hiroshi Inoue <Inoue@tpf.co.jp> writes:
|
||
> > SQL99's SQL-path is very clearly stated to be used only for looking up
|
||
> > routines and user-defined type names. Extending it to cover tables,
|
||
> > operators, and so forth makes sense to me,
|
||
>
|
||
> I have no objection to the point it makes sense to use
|
||
> such *path*s internally but I think it also has a siginificance
|
||
> for SQL-path to not look up _tables_like objects.
|
||
> I think they are different from the first and we should(need)
|
||
> not manage the system with one *path*.
|
||
|
||
I'm confused. Are you suggesting multiple paths? i.e. a function/type path
|
||
and a table one?
|
||
|
||
I think calling our path an SQL path is fine. Yes, we extend it by using
|
||
it for tables too, but it strikes me as still fundamentally an SQL path.
|
||
So I don't see why we should not call it that.
|
||
|
||
Take care,
|
||
|
||
Bill
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 6: Have you searched our list archives?
|
||
|
||
http://archives.postgresql.org
|
||
|
||
From pgsql-hackers-owner+M18342=candle.pha.pa.us=pgman@postgresql.org Thu Jan 31 11:56:06 2002
|
||
Return-path: <pgsql-hackers-owner+M18342=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0VGu5P13918
|
||
for <pgman@candle.pha.pa.us>; Thu, 31 Jan 2002 11:56:05 -0500 (EST)
|
||
Received: (qmail 32437 invoked by alias); 31 Jan 2002 16:53:56 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 31 Jan 2002 16:53:56 -0000
|
||
Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0VGdAl25623
|
||
for <pgsql-hackers@postgresql.org>; Thu, 31 Jan 2002 11:39:11 -0500 (EST)
|
||
(envelope-from wrstuden@netbsd.org)
|
||
Received: (qmail 29902 invoked by uid 1130); 31 Jan 2002 16:33:09 -0000
|
||
Date: Thu, 31 Jan 2002 08:28:10 -0800 (PST)
|
||
From: Bill Studenmund <wrstuden@netbsd.org>
|
||
X-X-Sender: <wrstuden@vespasia.home-net.internetconnect.net>
|
||
To: Hiroshi Inoue <Inoue@tpf.co.jp>
|
||
cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
|
||
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <3C58BBB3.58D5F964@tpf.co.jp>
|
||
Message-ID: <Pine.NEB.4.33.0201310827380.29090-100000@vespasia.home-net.internetconnect.net>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Thu, 31 Jan 2002, Hiroshi Inoue wrote:
|
||
|
||
> > it will definitely not
|
||
> > do to look for a table's datatype and get the wrong type. And I think
|
||
> > that functions and operators should be looked for on the same path
|
||
> > as datatypes, because a type should be pretty closely associated with
|
||
> > the functions/operators for it. So it seems to me that the apparent
|
||
> > flexibility of having more than one path is just a way to shoot yourself
|
||
> > in the foot. Why are you concerned that we keep them separate?
|
||
>
|
||
> For example, doesn't 'DROP table a_table' drop the
|
||
> a_table table in a schema in the *path* if there's
|
||
> no a_table table in the current schema ?
|
||
>
|
||
> If we would never introduce SQL-paths (in the future)
|
||
> there would be problem.
|
||
|
||
??
|
||
|
||
We're talking about adding them now. Why would we add them twice?
|
||
|
||
Take care,
|
||
|
||
Bill
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 4: Don't 'kill -9' the postmaster
|
||
|
||
From pgsql-hackers-owner+M18341=candle.pha.pa.us=pgman@postgresql.org Thu Jan 31 11:59:16 2002
|
||
Return-path: <pgsql-hackers-owner+M18341=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0VGxFP14456
|
||
for <pgman@candle.pha.pa.us>; Thu, 31 Jan 2002 11:59:15 -0500 (EST)
|
||
Received: (qmail 32440 invoked by alias); 31 Jan 2002 16:53:56 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 31 Jan 2002 16:53:56 -0000
|
||
Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0VGdAl25618
|
||
for <pgsql-hackers@postgresql.org>; Thu, 31 Jan 2002 11:39:11 -0500 (EST)
|
||
(envelope-from wrstuden@netbsd.org)
|
||
Received: (qmail 223 invoked by uid 1130); 31 Jan 2002 16:36:01 -0000
|
||
Date: Thu, 31 Jan 2002 08:31:03 -0800 (PST)
|
||
From: Bill Studenmund <wrstuden@netbsd.org>
|
||
X-X-Sender: <wrstuden@vespasia.home-net.internetconnect.net>
|
||
To: Tom Lane <tgl@sss.pgh.pa.us>
|
||
cc: Hiroshi Inoue <Inoue@tpf.co.jp>, Peter Eisentraut <peter_e@gmx.net>,
|
||
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <29733.1012448621@sss.pgh.pa.us>
|
||
Message-ID: <Pine.NEB.4.33.0201310828190.29090-100000@vespasia.home-net.internetconnect.net>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Wed, 30 Jan 2002, Tom Lane wrote:
|
||
|
||
> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
|
||
> > For example, doesn't 'DROP table a_table' drop the
|
||
> > a_table table in a schema in the *path* if there's
|
||
> > no a_table table in the current schema ?
|
||
>
|
||
> Sure. And that's exactly what it should do, IMHO.
|
||
> Otherwise the notion that you can ignore your private
|
||
> schema (at the front of the path) if you're not using
|
||
> it falls down. Also, we wouldn't be able to implement
|
||
> temp tables via a backend-local schema at the front of
|
||
> the path.
|
||
|
||
Well, I disagree on this one. :-) I'd vote drop should need a specific
|
||
schema if it's not the current one. But I won't push the point. :-)
|
||
|
||
> Any security concerns here should be addressed by putting
|
||
> ACLs on the schemas you don't want altered; not by contorting
|
||
> the notion of a search path to work for some operations and
|
||
> not others.
|
||
|
||
I'm not so concerned about security as being sure of operator intent. ACLs
|
||
address security (and should be used), but they don't address making sure
|
||
you delete exactly what you wanted.
|
||
|
||
Take care,
|
||
|
||
Bill
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
|
||
|
||
From pgsql-hackers-owner+M18341=candle.pha.pa.us=pgman@postgresql.org Thu Jan 31 12:00:40 2002
|
||
Return-path: <pgsql-hackers-owner+M18341=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0VH0dP14749
|
||
for <pgman@candle.pha.pa.us>; Thu, 31 Jan 2002 12:00:39 -0500 (EST)
|
||
Received: (qmail 32325 invoked by alias); 31 Jan 2002 16:53:51 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 31 Jan 2002 16:53:51 -0000
|
||
Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g0VGdAl25625
|
||
for <pgsql-hackers@postgresql.org>; Thu, 31 Jan 2002 11:39:12 -0500 (EST)
|
||
(envelope-from wrstuden@netbsd.org)
|
||
Received: (qmail 284 invoked by uid 1130); 31 Jan 2002 16:38:48 -0000
|
||
Date: Thu, 31 Jan 2002 08:33:50 -0800 (PST)
|
||
From: Bill Studenmund <wrstuden@netbsd.org>
|
||
X-X-Sender: <wrstuden@vespasia.home-net.internetconnect.net>
|
||
To: Hiroshi Inoue <Inoue@tpf.co.jp>
|
||
cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
|
||
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
In-Reply-To: <3C591E5E.14549DF@tpf.co.jp>
|
||
Message-ID: <Pine.NEB.4.33.0201310831290.29090-100000@vespasia.home-net.internetconnect.net>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Thu, 31 Jan 2002, Hiroshi Inoue wrote:
|
||
|
||
> Tom Lane wrote:
|
||
> >
|
||
> > Hiroshi Inoue <Inoue@tpf.co.jp> writes:
|
||
> > > For example, doesn't 'DROP table a_table' drop the
|
||
> > > a_table table in a schema in the *path* if there's
|
||
> > > no a_table table in the current schema ?
|
||
> >
|
||
> > Sure. And that's exactly what it should do, IMHO.
|
||
> > Otherwise the notion that you can ignore your private
|
||
> > schema (at the front of the path) if you're not using
|
||
> > it falls down. Also, we wouldn't be able to implement
|
||
> > temp tables via a backend-local schema at the front of
|
||
> > the path.
|
||
>
|
||
> I don't think it's useful for tables other than temp
|
||
> ones and I wouldn't use it other than for temp ones.
|
||
|
||
I agree.
|
||
|
||
> When we type 'rm a_file' in a shell environment
|
||
> does the *rm* command search the PATH in finding
|
||
> the a_file file ? Even though we need to implement
|
||
> such a search mechanism we would use another path
|
||
> different from the executable search PATH. I don't
|
||
> think our *path* is an extension of SQL-path.
|
||
>
|
||
> I wouldn't complain unless we call the *path*
|
||
> as SQL-path or an extension of SQL-path.
|
||
|
||
I still don't get this. The path we're talking about is the same thing
|
||
(with the same envirnment name and operational syntax) as SQL-paths,
|
||
except that we use it to find tables too. Why does that make it not an SQL
|
||
path?
|
||
|
||
Take care,
|
||
|
||
Bill
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 4: Don't 'kill -9' the postmaster
|
||
|
||
From pgsql-hackers-owner+M18346=candle.pha.pa.us=pgman@postgresql.org Thu Jan 31 20:15:10 2002
|
||
Return-path: <pgsql-hackers-owner+M18346=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g111FAP04980
|
||
for <pgman@candle.pha.pa.us>; Thu, 31 Jan 2002 20:15:10 -0500 (EST)
|
||
Received: (qmail 48143 invoked by alias); 1 Feb 2002 01:15:08 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 1 Feb 2002 01:15:08 -0000
|
||
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
|
||
by postgresql.org (8.11.3/8.11.4) with SMTP id g11181l47339
|
||
for <pgsql-hackers@postgresql.org>; Thu, 31 Jan 2002 20:08:01 -0500 (EST)
|
||
(envelope-from Inoue@tpf.co.jp)
|
||
Received: (qmail 14937 invoked from network); 1 Feb 2002 01:08:03 -0000
|
||
Received: from unknown (HELO viscomail.tpf.co.jp) (100.0.0.108)
|
||
by sd2.tpf-fw-c.co.jp with SMTP; 1 Feb 2002 01:08:03 -0000
|
||
Received: from tpf.co.jp (3dgateway1 [126.0.1.60])
|
||
by viscomail.tpf.co.jp (8.8.8+Sun/8.8.8) with ESMTP id KAA11846;
|
||
Fri, 1 Feb 2002 10:08:01 +0900 (JST)
|
||
Message-ID: <3C59EA75.E117B2FA@tpf.co.jp>
|
||
Date: Fri, 01 Feb 2002 10:08:05 +0900
|
||
From: Hiroshi Inoue <Inoue@tpf.co.jp>
|
||
X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U)
|
||
X-Accept-Language: ja
|
||
MIME-Version: 1.0
|
||
To: Bill Studenmund <wrstuden@netbsd.org>
|
||
cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
|
||
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects
|
||
References: <Pine.NEB.4.33.0201310831290.29090-100000@vespasia.home-net.internetconnect.net>
|
||
Content-Type: text/plain; charset=iso-2022-jp
|
||
Content-Transfer-Encoding: 7bit
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Bill Studenmund wrote:
|
||
>
|
||
> On Thu, 31 Jan 2002, Hiroshi Inoue wrote:
|
||
> >
|
||
> > I wouldn't complain unless we call the *path*
|
||
> > as SQL-path or an extension of SQL-path.
|
||
>
|
||
> I still don't get this. The path we're talking about is the same thing
|
||
> (with the same envirnment name and operational syntax) as SQL-paths,
|
||
> except that we use it to find tables too. Why does that make it not an SQL
|
||
> path?
|
||
|
||
I don't think It's always good to follow the standard.
|
||
However it's very wrong to change the meaning of words
|
||
in the standard. It seems impossible to introduce SQL-path
|
||
using our *path*. The *path* is PostgreSQL specific and
|
||
it would be configurable for us to be SQL99-compatible
|
||
(without SQL-path) or SQL99-imcompatible using the *path*.
|
||
|
||
regards,
|
||
Hiroshi Inoue
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 3: if posting/reading through Usenet, please send an appropriate
|
||
subscribe-nomail command to majordomo@postgresql.org so that your
|
||
message can get through to the mailing list cleanly
|
||
|