X-Original-To: pgsql-patches-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id DD9779DC9D4 for ; Mon, 13 Mar 2006 07:43:31 -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 21793-02 for ; Mon, 13 Mar 2006 07:43:33 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from svana.org (svana.org [125.62.94.225]) by postgresql.org (Postfix) with ESMTP id 0C0E19DC89F for ; Mon, 13 Mar 2006 07:43:29 -0400 (AST) Received: from kleptog by svana.org with local (Exim 4.50) id 1FIlSW-00026l-0L for pgsql-patches@postgresql.org; Mon, 13 Mar 2006 22:43:32 +1100 Date: Mon, 13 Mar 2006 12:43:31 +0100 From: Martijn van Oosterhout To: pgsql-patches@postgresql.org Subject: Re: Proposed patch for error locations Message-ID: <20060313114331.GC6714@svana.org> Reply-To: Martijn van Oosterhout Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5/uDoXvLw7AC5HRs" Content-Disposition: inline In-Reply-To: <5114.1142185055@sss.pgh.pa.us> X-PGP-Key-ID: Length=1024; ID=0x0DC67BE6 X-PGP-Key-Fingerprint: 295F A899 A81A 156D B522 48A7 6394 F08A 0DC6 7BE6 X-PGP-Key-URL: X-Warning: Normally my messages are signed, but not on the ozTiVo list due to legacy application support User-Agent: Mutt/1.5.9i X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: kleptog@svana.org X-SA-Exim-Scanned: No (on svana.org); SAEximRunCond expanded to false X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.123 required=5 tests=[AWL=0.123] X-Spam-Score: 0.123 X-Spam-Level: X-Archive-Number: 200603/168 X-Sequence-Number: 19172 --5/uDoXvLw7AC5HRs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > The attached WIP patch improves the parser so that cursor positions > can be attached to many errors reported during parse analysis, such > as complaints about nonexistent columns or functions. This is along > the lines proposed in my rant here: > http://archives.postgresql.org/pgsql-patches/2006-02/msg00234.php > to wit, that we make use of bison's "locations" feature to track > token positions in the grammar, and add locations to raw parse tree > nodes as needed. My only comment is: Wouldn't it be clearer in the long run to create a ParseNode base structure which is used in place of NodeTag for parsenodes, and put the "int location" in there. Then you could create a new function called makeParseNode which works like makeNode but takes an extra argument giving the location. Or some variation of the two. The thing I'm wondering is whether there will ever be any other information we want to store, like token length so you can bracket the expression and/or extract the exact expression with the issue. For example, the (start,end) of a function call includes everything within the brackets. By abstrating into a makeParseNode function, you may be able to avoid changing a lot of code down the line. Finally, is the count in characters or bytes (w.r.t. multibyte encodings)? Have a nice day, --=20 Martijn van Oosterhout http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them. --5/uDoXvLw7AC5HRs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEFVrjIB7bNG8LQkwRAkpUAJ9VtJEdCy0Ts3oCN9efd2tzwTRLuACfWchV aahpep47Mqj6RMyruUPIeXc= =WOR7 -----END PGP SIGNATURE----- --5/uDoXvLw7AC5HRs--