diff --git a/doc/TODO.detail/schema b/doc/TODO.detail/schema index f80ba5197e..b7c8464578 100644 --- a/doc/TODO.detail/schema +++ b/doc/TODO.detail/schema @@ -179,3 +179,7639 @@ On Tue, May 22, 2001 at 07:31:18AM -0400, Bruce Momjian wrote: > 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 +