From ronz@ravensfield.com Tue May 22 17:35:37 2001 Return-path: 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 ; 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 Organization: Ravensfield Geographic To: Bruce Momjian 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 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 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: 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 ; 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 ; 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 ; Wed, 23 May 2001 09:56:41 -0500 Date: Wed, 23 May 2001 09:56:41 -0500 From: "Ross J. Reedstrom" To: Bruce Momjian 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: Received: from 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 ; 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 ; 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 ; 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 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: Received: from 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 ; 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 ; 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 cc: Zeugswetter Andreas SB SD , 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 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 Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Fernando Nasser 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: Received: from 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 ; 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 ; 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 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 cc: Zeugswetter Andreas SB SD , 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 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: Received: from 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 ; 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 ; 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 ; 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 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: Received: from 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 ; 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 ; 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 ; 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 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: Received: from 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 ; 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 ; 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 X-Sender: To: Tom Lane cc: Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <11381.1011648592@sss.pgh.pa.us> Message-ID: 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 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: Received: from 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 ; 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 ; 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 cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: References: Comments: In-reply-to Peter Eisentraut 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 Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Peter Eisentraut 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: Received: from 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 ; 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 ; 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 Organization: CodeByDesign To: Tom Lane , Peter Eisentraut 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: <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: Received: from 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 ; 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 ; 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 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 cc: Peter Eisentraut , pgsql-hackers@postgresql.org Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects References: <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 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: Received: from 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 ; 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 ; 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 cc: Peter Eisentraut , pgsql-hackers@postgresql.org Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <3C4D8A39.FF79CDC4@redhat.com> References: <12239.1011661590@sss.pgh.pa.us> <3C4D8A39.FF79CDC4@redhat.com> Comments: In-reply-to Fernando Nasser 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 Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Fernando Nasser 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: Received: from 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 ; 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 ; 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 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 cc: Peter Eisentraut , pgsql-hackers@postgresql.org Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects References: <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: Received: from 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 ; 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 ; 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 cc: Peter Eisentraut , pgsql-hackers@postgresql.org Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <3C4D96C5.80BBF764@redhat.com> References: <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 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 Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Fernando Nasser 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: Received: from 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 ; 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 ; 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 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 cc: Peter Eisentraut , pgsql-hackers@postgresql.org Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects References: <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: Received: from 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 ; 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 ; 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 cc: Peter Eisentraut , pgsql-hackers@postgresql.org Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <3C4DCBDB.689D7201@redhat.com> References: <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 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 Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Fernando Nasser 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: Received: from 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 ; 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 ; 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 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 cc: Peter Eisentraut , pgsql-hackers@postgresql.org Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects References: <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: Received: from 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 ; 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 ; 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 cc: Peter Eisentraut , pgsql-hackers@postgresql.org Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <3C4DD34F.CC4D8B6@redhat.com> References: <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 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 Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Fernando Nasser 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: Received: from 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 ; 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 ; 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 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 cc: Peter Eisentraut , pgsql-hackers@postgresql.org Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects References: <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 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: Received: from 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 ; 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 ; 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 cc: Peter Eisentraut , pgsql-hackers@postgresql.org Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <3C4DD909.F26FD0D1@redhat.com> References: <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 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 Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Fernando Nasser 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: Received: from 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 ; 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 ; 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 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 cc: Peter Eisentraut , pgsql-hackers@postgresql.org Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects References: <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 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: Received: from 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 ; 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 ; 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 X-Sender: To: Tom Lane cc: Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <12239.1011661590@sss.pgh.pa.us> Message-ID: 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: Received: from 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 ; 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 ; 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 X-Sender: To: Tom Lane cc: Fernando Nasser , Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <28787.1011735287@sss.pgh.pa.us> Message-ID: 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: Received: from 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 ; 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 ; 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 cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: References: Comments: In-reply-to Peter Eisentraut 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 Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Peter Eisentraut 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: Received: from 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 ; 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 ; 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 cc: Fernando Nasser , pgsql-hackers@postgresql.org Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: References: Comments: In-reply-to Peter Eisentraut 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 Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Peter Eisentraut 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: Received: from 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 ; 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 ; 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" To: Tom Lane cc: Peter Eisentraut , 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" , Tom Lane , Peter Eisentraut , pgsql-hackers@postgresql.org References: <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 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: Received: from 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 ; 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 ; 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 X-X-Sender: To: Tom Lane cc: Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <11381.1011648592@sss.pgh.pa.us> Message-ID: 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: Received: from 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 ; 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 ; 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 ; 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 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: <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: Received: from 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 ; 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 ; 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 X-Sender: To: Tom Lane cc: Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <29288.1011742268@sss.pgh.pa.us> Message-ID: 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: Received: from 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 ; 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 ; 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 cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: References: Comments: In-reply-to Bill Studenmund 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 Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Bill Studenmund 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: Received: from 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 ; 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 ; 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 X-Sender: To: Tom Lane cc: Bill Studenmund , Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <648.1011762477@sss.pgh.pa.us> Message-ID: 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: Received: from 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 ; 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 ; 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" To: "Tom Lane" , "Fernando Nasser" cc: "Peter Eisentraut" , 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: Received: from 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 ; 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 ; 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" To: "Peter Eisentraut" , "Tom Lane" cc: "Bill Studenmund" , 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: Received: from 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 ; 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 ; 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 ; Wed, 23 Jan 2002 11:03:18 -0000 Message-ID: From: "Henshall, Stuart - WCP" To: "'Tom Lane'" , Peter Eisentraut cc: Fernando Nasser , 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 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: Received: from 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 ; 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 ; 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" cc: Peter Eisentraut , Fernando Nasser , pgsql-hackers@postgresql.org Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: References: Comments: In-reply-to "Henshall, Stuart - WCP" 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 Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR "Henshall, Stuart - WCP" 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: Received: from 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 ; 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 ; 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 cc: pgsql-hackers@postgresql.org, Fernando Nasser Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: References: Comments: In-reply-to Peter Eisentraut 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 Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Peter Eisentraut 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: Received: from 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 ; 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 ; 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" cc: "Fernando Nasser" , "Peter Eisentraut" , 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" 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 Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: ORr "Zeugswetter Andreas SB SD" 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: Received: from 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 ; 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 ; 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 To: Tom Lane cc: Peter Eisentraut , , Fernando Nasser 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: Received: from 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 ; 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 ; 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 cc: Peter Eisentraut , pgsql-hackers@postgresql.org, Fernando Nasser 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 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 Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Stephan Szabo 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: Received: from 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 ; 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 ; 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)" 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 cc: Zeugswetter Andreas SB SD , Fernando Nasser , Peter Eisentraut , 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: Received: from 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 ; 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 ; 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)" cc: Zeugswetter Andreas SB SD , Fernando Nasser , Peter Eisentraut , 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)" 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 Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR "Joe Conway (wwc)" 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: Received: from 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 ; 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 ; 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 To: Tom Lane cc: Peter Eisentraut , , Fernando Nasser 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 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: Received: from 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 ; 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 ; 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 X-X-Sender: To: Tom Lane cc: Peter Eisentraut , Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <12239.1011661590@sss.pgh.pa.us> Message-ID: 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 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: Received: from 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 ; 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 ; 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 cc: Peter Eisentraut , pgsql-hackers@postgresql.org Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: References: Comments: In-reply-to Bill Studenmund 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 Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Bill Studenmund 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: Received: from 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 ; 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 ; 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 X-X-Sender: To: Tom Lane cc: Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <648.1011762477@sss.pgh.pa.us> Message-ID: 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 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: Received: from 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 ; 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 ; 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 cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: References: Comments: In-reply-to Bill Studenmund 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 Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Bill Studenmund writes: > On Wed, 23 Jan 2002, Tom Lane wrote: >> Bill Studenmund 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: Received: from 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 ; 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 ; 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 X-X-Sender: To: Tom Lane cc: Peter Eisentraut , Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <5078.1011815834@sss.pgh.pa.us> Message-ID: 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 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: Received: from 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 ; 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 ; 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 X-X-Sender: To: Tom Lane cc: Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <8533.1011819436@sss.pgh.pa.us> Message-ID: 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 writes: > > On Wed, 23 Jan 2002, Tom Lane wrote: > >> Bill Studenmund 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: Received: from 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 ; 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 ; 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 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 cc: Stephan Szabo , Peter Eisentraut , pgsql-hackers@postgresql.org, Fernando Nasser 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 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 addit ion, including cases that
had nothing obvious to do with either int4 or int8 ...
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... )

Then you could just be really hard and say that only exact and trivial conversion matches in user space will be used .  

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.

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.)


regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org


From pgsql-hackers-owner+M18066=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 16:45:11 2002 Return-path: Received: from 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 ; 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 ; 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 cc: Peter Eisentraut , pgsql-hackers@postgresql.org Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: References: Comments: In-reply-to Bill Studenmund 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 Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Bill Studenmund 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: Received: from 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 ; 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 ; 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 cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: References: Comments: In-reply-to Bill Studenmund 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 Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Bill Studenmund 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: Received: from 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 ; 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 ; 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 X-X-Sender: To: Tom Lane cc: Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <8842.1011822361@sss.pgh.pa.us> Message-ID: 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 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: Received: from 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 ; 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 ; 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 X-X-Sender: To: Tom Lane cc: Peter Eisentraut , , Fernando Nasser Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <2600.1011799885@sss.pgh.pa.us> Message-ID: 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 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: Received: from 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 ; 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 ; 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 X-X-Sender: To: Tom Lane cc: Zeugswetter Andreas SB SD , Fernando Nasser , Peter Eisentraut , Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <2677.1011800674@sss.pgh.pa.us> Message-ID: 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" 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::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: Received: from 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 ; 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 ; 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 X-X-Sender: To: Tom Lane cc: Peter Eisentraut , Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <8747.1011821193@sss.pgh.pa.us> Message-ID: 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 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: Received: from 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 ; 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 ; 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 To: Bill Studenmund cc: Tom Lane , Peter Eisentraut , , Fernando Nasser Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: 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: Received: from 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 ; 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 ; 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 X-X-Sender: To: Stephan Szabo cc: Tom Lane , Peter Eisentraut , , Fernando Nasser Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <20020123152711.I22382-100000@megazone23.bigpanda.com> Message-ID: 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: Received: from 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 ; 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 ; 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 To: Bill Studenmund cc: Tom Lane , Peter Eisentraut , , Fernando Nasser Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: 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: Received: from 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 ; 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 ; 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 X-X-Sender: To: Stephan Szabo cc: Tom Lane , Peter Eisentraut , , Fernando Nasser Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <20020123155603.Y22713-100000@megazone23.bigpanda.com> Message-ID: 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: Received: from 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 ; 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 ; 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 To: Bill Studenmund cc: Tom Lane , Peter Eisentraut , , Fernando Nasser Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: 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: Received: from 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 ; 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 ; 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 X-X-Sender: To: Stephan Szabo cc: Tom Lane , Peter Eisentraut , , Fernando Nasser Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <20020123162426.K22713-100000@megazone23.bigpanda.com> Message-ID: 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: Received: from 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 ; 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 ; 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 To: Bill Studenmund cc: Tom Lane , Peter Eisentraut , , Fernando Nasser Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: 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: Received: from 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 ; 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 ; 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 X-Sender: To: Bill Studenmund cc: Stephan Szabo , Tom Lane , PostgreSQL Development , Fernando Nasser Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: Message-ID: 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: Received: from 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 ; 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 ; 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 X-X-Sender: To: Stephan Szabo cc: Tom Lane , Peter Eisentraut , , Fernando Nasser Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <20020123165321.K23306-100000@megazone23.bigpanda.com> Message-ID: 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: Received: from 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 ; 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 ; 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 X-X-Sender: To: Peter Eisentraut cc: Stephan Szabo , Tom Lane , PostgreSQL Development , Fernando Nasser Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: Message-ID: 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: Received: from 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 ; 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 ; 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 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 Date: Thu, 24 Jan 2002 22:23:22 -0500 (EST) cc: Zeugswetter Andreas SB SD , Fernando Nasser , Peter Eisentraut , 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" 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: Received: from 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 ; 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 ; 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 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 Date: Thu, 24 Jan 2002 22:26:43 -0500 (EST) cc: Zeugswetter Andreas SB SD , Fernando Nasser , Peter Eisentraut , 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: Received: from 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 ; 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 ; 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 X-Sender: To: Tom Lane cc: Zeugswetter Andreas SB SD , Fernando Nasser , Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <2677.1011800674@sss.pgh.pa.us> Message-ID: 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: Received: from 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 ; 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 ; 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 cc: Zeugswetter Andreas SB SD , Fernando Nasser , pgsql-hackers@postgresql.org Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: References: Comments: In-reply-to Peter Eisentraut 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 Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Peter Eisentraut 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: Received: from 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 ; 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 ; 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 To: Tom Lane cc: Bill Studenmund , 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: 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: Received: from 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 ; 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 ; 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 Message-ID: <200201250433.g0P4XqD10470@candle.pha.pa.us> Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: To: Peter Eisentraut Date: Thu, 24 Jan 2002 23:33:52 -0500 (EST) cc: Tom Lane , Zeugswetter Andreas SB SD , Fernando Nasser , 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: Received: from 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 ; 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 ; 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 X-Sender: To: Tom Lane cc: Bill Studenmund , Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <8842.1011822361@sss.pgh.pa.us> Message-ID: 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: Received: from 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 ; 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 ; 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 cc: Bill Studenmund , pgsql-hackers@postgresql.org Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: References: Comments: In-reply-to Peter Eisentraut 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 Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Peter Eisentraut 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: Received: from 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 ; 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 ; 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 Message-ID: <200201250555.g0P5tWY15824@candle.pha.pa.us> Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: To: Peter Eisentraut Date: Fri, 25 Jan 2002 00:55:32 -0500 (EST) cc: Tom Lane , Zeugswetter Andreas SB SD , Fernando Nasser , 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: Received: from 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 ; 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 ; 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" To: "Joe Conway (wwc)" , "Tom Lane" cc: "Fernando Nasser" , "Peter Eisentraut" , 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: Received: from 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 ; 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 ; 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 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 Date: Fri, 25 Jan 2002 11:52:04 -0500 (EST) cc: "Joe Conway (wwc)" , Tom Lane , Fernando Nasser , Peter Eisentraut , 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: 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 ; 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 cc: Zeugswetter Andreas SB SD , "Joe Conway (wwc)" , Fernando Nasser , Peter Eisentraut , 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 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 Status: OR Bruce Momjian 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: Received: from 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 ; 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 ; 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 X-X-Sender: To: Gavin Sherry cc: Tom Lane , Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: Message-ID: 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: 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 ; 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" To: "Bruce Momjian" cc: "Joe Conway (wwc)" , "Tom Lane" , "Fernando Nasser" , "Peter Eisentraut" , 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: 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 ; 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 X-X-Sender: To: Bruce Momjian cc: Tom Lane , Zeugswetter Andreas SB SD , Fernando Nasser , Peter Eisentraut , Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <200201250326.g0P3Qhw23061@candle.pha.pa.us> Message-ID: 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: 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 ; 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 cc: Bruce Momjian , Zeugswetter Andreas SB SD , Fernando Nasser , Peter Eisentraut , pgsql-hackers@postgresql.org Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: References: Comments: In-reply-to Bill Studenmund 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 Status: OR Bill Studenmund 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: Received: from 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 ; 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 ; 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 X-X-Sender: To: Tom Lane cc: Bruce Momjian , Zeugswetter Andreas SB SD , Fernando Nasser , Peter Eisentraut , Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <7708.1011997574@sss.pgh.pa.us> Message-ID: 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 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: 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 ; 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 cc: Bruce Momjian , Zeugswetter Andreas SB SD , Fernando Nasser , Peter Eisentraut , pgsql-hackers@postgresql.org Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: References: Comments: In-reply-to Bill Studenmund 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 Status: OR Bill Studenmund 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: 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 ; 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 X-X-Sender: To: Tom Lane cc: Bruce Momjian , Zeugswetter Andreas SB SD , Fernando Nasser , Peter Eisentraut , Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <8233.1012003455@sss.pgh.pa.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: OR On Fri, 25 Jan 2002, Tom Lane wrote: > Bill Studenmund 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: Received: from 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 ; 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 ; 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 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 cc: Stephan Szabo , Peter Eisentraut , pgsql-hackers@postgresql.org, Fernando Nasser 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: Received: from 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 ; 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 ; 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 X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U) X-Accept-Language: ja MIME-Version: 1.0 To: Peter Eisentraut , Tom Lane cc: Bill Studenmund , Stephan Szabo , PostgreSQL Development , Fernando Nasser Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects References: 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: Received: from 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 ; 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 ; 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 X-X-Sender: To: Hiroshi Inoue cc: Peter Eisentraut , Tom Lane , Stephan Szabo , PostgreSQL Development , Fernando Nasser Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <3C54AA51.64CE68AD@tpf.co.jp> Message-ID: 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: Received: from 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 ; 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 ; 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 X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U) X-Accept-Language: ja MIME-Version: 1.0 To: Bill Studenmund cc: Peter Eisentraut , Tom Lane , Stephan Szabo , PostgreSQL Development , Fernando Nasser Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects References: 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: Received: from 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 ; 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 ; 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 X-X-Sender: To: Hiroshi Inoue cc: Peter Eisentraut , Tom Lane , Stephan Szabo , PostgreSQL Development , Fernando Nasser Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <3C56376C.BCA5B3A5@tpf.co.jp> Message-ID: 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: Received: from 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 ; 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 ; 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 X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U) X-Accept-Language: ja MIME-Version: 1.0 To: Bill Studenmund , Peter Eisentraut , Tom Lane cc: PostgreSQL Development Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects References: 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: Received: from 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 ; 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 ; 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 X-X-Sender: To: Hiroshi Inoue cc: Peter Eisentraut , Tom Lane , PostgreSQL Development Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <3C573C5E.F01B48C2@tpf.co.jp> Message-ID: 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: Received: from 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 ; 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 ; 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 cc: Bill Studenmund , Peter Eisentraut , pgsql-hackers@postgresql.org, Fernando Nasser 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 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 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 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: Received: from 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 ; 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 ; 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 X-X-Sender: To: Tom Lane cc: Stephan Szabo , Peter Eisentraut , , Fernando Nasser Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <26125.1012425144@sss.pgh.pa.us> Message-ID: 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: Received: from 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 ; 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 ; 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 cc: Bill Studenmund , Peter Eisentraut , PostgreSQL Development Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <3C573C5E.F01B48C2@tpf.co.jp> References: <3C573C5E.F01B48C2@tpf.co.jp> Comments: In-reply-to Hiroshi Inoue 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 Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Hiroshi Inoue 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: Received: from 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 ; 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 ; 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 X-X-Sender: To: Tom Lane cc: Hiroshi Inoue , Peter Eisentraut , PostgreSQL Development Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <27527.1012432386@sss.pgh.pa.us> Message-ID: 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 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: Received: from 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 ; 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 ; 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 X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U) X-Accept-Language: ja MIME-Version: 1.0 To: Bill Studenmund cc: Peter Eisentraut , Tom Lane , PostgreSQL Development Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects References: 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: Received: from 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 ; 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 ; 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 X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U) X-Accept-Language: ja MIME-Version: 1.0 To: Tom Lane cc: Bill Studenmund , Peter Eisentraut , PostgreSQL Development Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects References: <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 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: Received: from 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 ; 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 ; 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 cc: Bill Studenmund , Peter Eisentraut , PostgreSQL Development Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <3C58A472.2E90C21C@tpf.co.jp> References: <3C573C5E.F01B48C2@tpf.co.jp> <27527.1012432386@sss.pgh.pa.us> <3C58A472.2E90C21C@tpf.co.jp> Comments: In-reply-to Hiroshi Inoue 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 Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Hiroshi Inoue 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: Received: from 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 ; 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 ; 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 X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U) X-Accept-Language: ja MIME-Version: 1.0 To: Tom Lane cc: Bill Studenmund , Peter Eisentraut , PostgreSQL Development Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects References: <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 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: Received: from 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 ; 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 ; 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 cc: Bill Studenmund , Peter Eisentraut , PostgreSQL Development Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <3C58BBB3.58D5F964@tpf.co.jp> References: <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 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 Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Hiroshi Inoue 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: Received: from 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 ; 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 ; 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 X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U) X-Accept-Language: ja MIME-Version: 1.0 To: Tom Lane cc: Bill Studenmund , Peter Eisentraut , PostgreSQL Development Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects References: <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 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: Received: from 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 ; 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 ; 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 cc: Bill Studenmund , Peter Eisentraut , PostgreSQL Development Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <3C58BE48.AD4EE527@tpf.co.jp> References: <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 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 Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Status: OR Hiroshi Inoue 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: Received: from 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 ; 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 ; 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 X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U) X-Accept-Language: ja MIME-Version: 1.0 To: Tom Lane cc: Bill Studenmund , Peter Eisentraut , PostgreSQL Development Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects References: <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 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: Received: from 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 ; 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 ; 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 X-X-Sender: To: Hiroshi Inoue cc: Tom Lane , Peter Eisentraut , PostgreSQL Development Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <3C58A472.2E90C21C@tpf.co.jp> Message-ID: 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 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: Received: from 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 ; 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 ; 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 X-X-Sender: To: Hiroshi Inoue cc: Tom Lane , Peter Eisentraut , PostgreSQL Development Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <3C58BBB3.58D5F964@tpf.co.jp> Message-ID: 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: Received: from 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 ; 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 ; 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 X-X-Sender: To: Tom Lane cc: Hiroshi Inoue , Peter Eisentraut , PostgreSQL Development Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <29733.1012448621@sss.pgh.pa.us> Message-ID: 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 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: Received: from 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 ; 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 ; 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 X-X-Sender: To: Hiroshi Inoue cc: Tom Lane , Peter Eisentraut , PostgreSQL Development Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects In-Reply-To: <3C591E5E.14549DF@tpf.co.jp> Message-ID: 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 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: Received: from 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 ; 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 ; 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 X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U) X-Accept-Language: ja MIME-Version: 1.0 To: Bill Studenmund cc: Tom Lane , Peter Eisentraut , PostgreSQL Development Subject: Re: [HACKERS] RFD: schemas and different kinds of Postgres objects References: 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