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: 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 X-Archive-Number: 200201/1080 X-Sequence-Number: 18061 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