diff --git a/doc/TODO.detail/schema b/doc/TODO.detail/schema
deleted file mode 100644
index b7c8464578597c2bdbd72b2fdba29c9f7b8b494a..0000000000000000000000000000000000000000
--- a/doc/TODO.detail/schema
+++ /dev/null
@@ -1,7817 +0,0 @@
-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 (
- event_id INTEGER REFERENCES WEBCAL.tasks(event_id) ON DELETE CASCADE,
- user_id VARCHAR2(25) REFERENCES SERVICES.users(user_id) ON DELETE CASCADE,
- confirmed CHAR(1),
- PRIMARY KEY (event_id,user_id)
-);
-
-A join between tables in would be
-SELECT A.SAMPLE_ID,
- A.CONCENTRATION,
- A.CASNO,
- B.PARAMETER,
- C.DESCRIPTION AS STYPE
- FROM HAI.RESULTS A, SAMPLETRACK.PARAMETERS B,
-SAMPLETRACK.SAMPLE_TYPE C
- 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
-