diff options
Diffstat (limited to 'doc/TODO.detail')
| -rw-r--r-- | doc/TODO.detail/schema | 7817 |
1 files changed, 0 insertions, 7817 deletions
diff --git a/doc/TODO.detail/schema b/doc/TODO.detail/schema deleted file mode 100644 index b7c8464578..0000000000 --- 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 - |