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-15 22:45:49
Message-ID: 3087634.1615848349@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:
> For example:
> $ python3.5 -c "import pg; db=pg.DB(); q = db.query(\"SET log_parameter_max_length_on_error=-1;\"); db.prepare('p', 'SELECT \$1::smallint'); db.query_prepared('p',66666);"
> 2021-01-03 02:21:04.547 CST [20157] ERROR: value "66666" is out of range for type smallint
> 2021-01-03 02:21:04.547 CST [20157] CONTEXT: unnamed portal with parameters: $1 = '66666'
> 2021-01-03 02:21:04.547 CST [20157] STATEMENT: SELECT $1::smallint

> When there are many bind params, this can be useful to determine which is out
> of range. Think 900 int/smallint columns, or less-wide tables being inserted
> multiple rows at a time with VALUES(),(),()...

> Of course, this isn't as good as showing the column name, so I might pursue
> Tom's suggestion for that at some point.

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?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2021-03-15 22:49:45 Re: [PATCH]: Allow errors in parameter values to be reported during the BIND phase itself..
Previous Message Rafal Pietrak 2021-03-15 22:24:21 Re: Fwd: row level security (RLS)