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

Re: Attaching error cursor position to invalid constant values

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Brendan Jurd" <direvus(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Attaching error cursor position to invalid constant values
Date: 2008-08-31 05:27:27
Message-ID: 87vdxh4uv4.fsf@oxford.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> and I don't recall having heard any complaints about that.  I was just a
> bit shell-shocked by the number of regression test diffs my patch
> generated.  But on looking closer, the reason is the intentional testing
> of bad values in a lot of the datatype-specific tests.  So that's
> probably not a good indicator of how chatty it'll seem to regular users.

The only logical argument I see here for why this case is any different is
that since the constant is present in the original query and it's repeated in
the error the user has enough information to immediately identify the source
of the error. That's not true for other types of errors where the site of the
error isn't obvious from the error message.

But even for constants it's not entirely true either. You could have something
like:

select 'foo'+0, 'foo'+0.0;

and when you get the error the you would have to deduce which constant is in
error based on the type it describes. That could be quite a bit more complex
than this example.

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!

In response to

pgsql-hackers by date

Next:From: Dean RasheedDate: 2008-08-31 09:04:45
Subject: Re: Auto-explain patch
Previous:From: Tom LaneDate: 2008-08-31 05:13:05
Subject: Re: Attaching error cursor position to invalid constant values

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