X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id CE32CD1B550 for ; Sat, 24 Apr 2004 12:45:01 -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 45521-01 for ; Sat, 24 Apr 2004 12:45:00 -0300 (ADT) Received: from www.postgresql.com (www.postgresql.com [200.46.204.209]) by svr1.postgresql.org (Postfix) with ESMTP id ABAD7D1B514 for ; Sat, 24 Apr 2004 12:44:54 -0300 (ADT) Received: from 216.155.88.75.dsl.surnet.cl (200.85.195.254.DSL.surnet.cl [200.85.195.254]) by www.postgresql.com (Postfix) with ESMTP id 6A6B0CF4CD4 for ; Sat, 24 Apr 2004 12:44:04 -0300 (ADT) Received: by 216.155.88.75.dsl.surnet.cl (Postfix, from userid 500) id 81AD5151B9; Sat, 24 Apr 2004 11:40:22 -0400 (CLT) Date: Sat, 24 Apr 2004 11:40:22 -0400 From: Alvaro Herrera To: Joe Conway Cc: Tom Lane , Stephan Szabo , Shachar Shemesh , Robert Treat , Dennis Bjorklund , Bruce Momjian , PostgreSQL-development Subject: Re: [pgsql-advocacy] What can we learn from MySQL? Message-ID: <20040424154022.GA2927@dcc.uchile.cl> 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> <7305.1082779876@sss.pgh.pa.us> <408A019B.4060307@joeconway.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <408A019B.4060307@joeconway.com> User-Agent: Mutt/1.5.5.1i X-Virus-Scanned: by amavisd-new at postgresql.org X-Spam-Status: No, hits=3.7 tagged_above=0.0 required=5.0 tests=RCVD_IN_DSBL, RCVD_IN_DYNABLOCK, RCVD_IN_SORBS X-Spam-Level: *** X-Archive-Number: 200404/797 X-Sequence-Number: 52719 On Fri, Apr 23, 2004 at 10:56:43PM -0700, Joe Conway wrote: > Tom Lane wrote: > >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.) > > Shouldn't apps only really be querying the information schema if they're > expecting spec compliant behavior? If so, a GUC variable with an access > function ought to be enough to get up or down casing as desired, I'd think. Some questions: Is there a way to make this work? At what level should the current system be modified? If the parser or lexer is to be modified, are they going to need database access? They are not allowed to, AFAIR. One could invent a GUC setting for this, and have it set at database creation time. How would shared catalogs be handled? Should we have a template database for uppercase and another one for lower case databases? Should non-shared catalogs be handled in a special way? Or maybe it is a compilation switch. What issues would arise? -- Alvaro Herrera () "Before you were born your parents weren't as boring as they are now. They got that way paying your bills, cleaning up your room and listening to you tell them how idealistic you are." -- Charles J. Sykes' advice to teenagers