X-Original-To: pgsql-advocacy-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id ACB9FD1BA93 for ; Sat, 24 Apr 2004 01:11:24 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id 06826-04 for ; Sat, 24 Apr 2004 01:11:23 -0300 (ADT) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by svr1.postgresql.org (Postfix) with ESMTP id A4E8CD1BACC for ; Sat, 24 Apr 2004 01:11:22 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.11/8.12.11) with ESMTP id i3O4BGIq007306; Sat, 24 Apr 2004 00:11:16 -0400 (EDT) To: Stephan Szabo Cc: Shachar Shemesh , Robert Treat , Dennis Bjorklund , Bruce Momjian , PostgreSQL-development , PostgreSQL advocacy Subject: Re: [HACKERS] What can we learn from MySQL? In-reply-to: <20040423132913.X22334@megazone.bigpanda.com> References: <1082735128.22969.1106.camel@camel> <20040423094236.J17459@megazone.bigpanda.com> <40897131.6020902@shemesh.biz> <20040423130701.K21905@megazone.bigpanda.com> <20040423132913.X22334@megazone.bigpanda.com> Comments: In-reply-to Stephan Szabo message dated "Fri, 23 Apr 2004 13:31:16 -0700" Date: Sat, 24 Apr 2004 00:11:16 -0400 Message-ID: <7305.1082779876@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at postgresql.org X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests= X-Spam-Level: X-Archive-Number: 200404/175 X-Sequence-Number: 4147 Stephan Szabo writes: > To clarify, I'm thinking about things where an application had gotten a > quoted name and is now trying to use it where the object's canonical name > was changed due to quoting changes. This only happens when quoting > is inconsistently applied, but that's most of the problem. Actually, that's *all* the problem, at least as far as SQL commands are concerned. If you are consistent about always quoting or never quoting a particular name, you can't tell the difference between PG's behavior and SQL-spec behavior. Aside from the reality that apps aren't very consistent about their quoting behavior, the fly in this ointment is that whenever you query the database catalogs you will see the stored spelling of the name. So apps that rely on seeing the same spelling in the catalog that they entered could break. (In practice this doesn't seem to be as big a problem as the sloppy-quoting-behavior issue, though.) Personally I don't think that this is a "transitional issue" and we will someday all be happy in upper-case-only-land. Upper-case-only sucks, by every known measure of readability, and I don't want to have to put up with a database that forces that 1960s-vintage-hardware mindset on me. So what I'm holding out for is a design that lets me continue to see the current behavior if I set a GUC variable that says that's what I want. This seems possible (not easy, but possible) if we are willing to require the choice to be made at compile time ... but that sounds too restrictive to satisfy anybody ... what we need is a design that supports such a choice per-session, and I dunno how to do that. regards, tom lane PS: I resisted the temptation to SET THIS MESSAGE IN ALL UPPER CASE to make the point about readability. But if you want to argue the point with me, I'll be happy to do that for the rest of the thread.