Skip site navigation (1) Skip section navigation (2)

Re: Proposed patch for error locations

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: Proposed patch for error locations
Date: 2006-03-13 15:44:24
Message-ID: 7550.1142264664@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-interfacespgsql-patches
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> 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.

Only if we really wanted *every* parse node to carry a location, which
I think is overkill.  If we took it far enough we'd be needing location
decoration on List nodes too, and that is definitely not happening.

There's a tradeoff here between completeness of information and
performance.  In some quick tests with pgbench I don't detect any
noticeable performance loss with the patch as proposed, but it'd be
very easy to cross the threshold to where it does cost performance,
if we get too excited about decorating parse nodes with more than a
minimal amount of overhead.

> Finally, is the count in characters or bytes (w.r.t. multibyte
> encodings)?

Bytes; see the comments.  Converting to a character count only happens
if an actual error message has to be emitted.  (This is uglier than I
would like, but I don't see any sufficiently-cheap way to get the lexer
to count multibyte characters correctly.)

			regards, tom lane

In response to

pgsql-patches by date

Next:From: Tom LaneDate: 2006-03-13 15:57:07
Subject: Re: Proposed p.tch for error locations
Previous:From: Alvaro HerreraDate: 2006-03-13 15:32:09
Subject: Re: Proposed p.tch for error locations

pgsql-interfaces by date

Next:From: Volkan YAZICIDate: 2006-03-13 15:55:31
Subject: Re: Receiving SIGPIPE for PQfinish(<broken-connection>)
Previous:From: Alvaro HerreraDate: 2006-03-13 15:32:09
Subject: Re: Proposed p.tch for error locations

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group