X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 1671F9DD4F3 for ; Fri, 13 Jan 2006 01:10:34 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 14135-02 for ; Fri, 13 Jan 2006 01:10:32 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id CD2A29DD4D2 for ; Fri, 13 Jan 2006 01:10:31 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id k0D5ATwv021659; Fri, 13 Jan 2006 00:10:29 -0500 (EST) To: Michael Fuhr cc: John DeSoi , pgsql-hackers@postgreSQL.org Subject: Re: [SQL] info is a reserved word? In-reply-to: <20060113045756.GA88336@winnie.fuhr.org> References: <304B868D-CE4E-4E43-8B85-4CA238BB0F94@pgedit.com> <20060113012932.GA71559@winnie.fuhr.org> <21184.1137126088@sss.pgh.pa.us> <20060113045756.GA88336@winnie.fuhr.org> Comments: In-reply-to Michael Fuhr message dated "Thu, 12 Jan 2006 21:57:56 -0700" Date: Fri, 13 Jan 2006 00:10:29 -0500 Message-ID: <21658.1137129029@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.087 required=5 tests=[AWL=0.087] X-Spam-Score: 0.087 X-Spam-Level: X-Archive-Number: 200601/390 X-Sequence-Number: 78494 [ moved to -hackers ] Michael Fuhr writes: > On Thu, Jan 12, 2006 at 11:21:28PM -0500, Tom Lane wrote: >> plpgsql is not very good about reserving words "minimally", ie, not >> treating a word as a keyword outside the context where the keyword >> is meaningful. >> >> This could probably be fixed, or at least greatly reduced, with some >> flex/bison hacking. Anyone up for it? > Possibly. Would it involve much more than what the main parser's > grammar does with unreserved_keyword and friends? I suppose this > ought to move to pgsql-hackers. The keyword-classification tactic would be one approach. For the specific case of the RAISE severity codes, I'd be inclined to eliminate all those "keywords" entirely and let them be lexed/parsed as simple identifiers --- there's no strong reason not to do strcmp's for specific identifiers at the point where we're building a raise_level value. There are probably some other methods that might apply in other places. But in any case it's a fairly self-contained problem; you don't need any vast knowledge of Postgres internals to tackle it, just some understanding of the flex and bison tools. regards, tom lane