Re: Add schema-qualified relnames in constraint error messages.

From: Alex Shulgin <alex(dot)shulgin(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de>, Daniel Verite <daniel(at)manitou-mail(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add schema-qualified relnames in constraint error messages.
Date: 2016-04-03 04:46:06
Message-ID: CAM-UEKRpRykDz1sA3OimhjY=dOpWyuBMEf8rDxtWzBP7WB14Lg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Apr 2, 2016 at 11:41 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de> writes:
> > On Mon, Mar 14, 2016 at 7:55 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> Yeah, I don't much like that either. But I don't think we can avoid
> >> some refactoring there; as designed, conversion of an error message into
> >> user-visible form is too tightly tied to receipt of the message.
>
> > True. Attached is a v2 which addresses all of the points raised earlier
> I
> > believe.
>
> I took a closer look at what's going on here and realized that actually
> it's not that hard to decouple the message-building routine from the
> PGconn state, because mostly it works with fields it's extracting out
> of the PGresult anyway. The only piece of information that's lacking
> is conn->last_query. I propose therefore that instead of doing it like
> this, we copy last_query into error PGresults. This is strictly less
> added storage requirement than storing the whole verbose message would be,
> and it saves time compared to the v2 patch in the typical case where
> the application never does ask for an alternately-formatted error message.
> Plus we can actually support requests for any variant format, not only
> VERBOSE.
>
> Attached is a libpq-portion-only version of a patch doing it this way.
> I've not yet looked at the psql part of your patch.
>
> Comments?
>

Ah, neat, that's even better. :-)

What about regression tests? My assumption was that we won't be able to
add them with the usual expected file approach, but that we also don't need
it that hard. Everyone's in favor?

--
Alex

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alex Shulgin 2016-04-03 04:59:16 Re: More stable query plans via more predictable column statistics
Previous Message Dilip Kumar 2016-04-03 04:25:12 Re: Move PinBuffer and UnpinBuffer to atomics