Re: [PATCH]: Allow errors in parameter values to be reported during the BIND phase itself..

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Alexey Bashtanov <bashtanov(at)imap(dot)cc>, Franck Verrot <franck(at)verrot(dot)fr>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH]: Allow errors in parameter values to be reported during the BIND phase itself..
Date: 2021-03-16 00:30:18
Message-ID: 3140512.1615854618@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Justin Pryzby <pryzby(at)telsasoft(dot)com> writes:
> On Mon, Mar 15, 2021 at 06:45:49PM -0400, Tom Lane wrote:
>> I started to look at this, and immediately began to wonder where is the
>> previous discussion you're evidently referring to. Can you dig up an
>> archives link?

> I think I was referring to this (from the commit message).
> https://www.postgresql.org/message-id/flat/CANfkH5k-6nNt-4cSv1vPB80nq2BZCzhFVR5O4VznYbsX0wZmow(at)mail(dot)gmail(dot)com

Got it, thanks.

After studying the patch it seems like there's a better way to do it:
we should just log the single parameter that's at fault. That saves
the user from having to dig through a bunch of parameters to figure
out which one we're complaining about, plus we can usefully identify
the parameter (by number) even if it was sent in binary.

This is a little bit more net code addition than what you had,
but only by ten lines or so. On the plus side, it doesn't
require rearranging any existing code.

regards, tom lane

Attachment Content-Type Size
0001-identify-bad-bind-parameters.patch text/x-diff 4.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Laurenz Albe 2021-03-16 01:00:16 Re: Enhance traceability of wal_level changes for backup management
Previous Message Peter Geoghegan 2021-03-16 00:00:33 Re: New IndexAM API controlling index vacuum strategies