|From:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|To:||Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>|
|Cc:||Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: extend pgbench expressions with functions|
|Views:||Raw Message | Whole Thread | Download mbox|
On Wed, Mar 9, 2016 at 3:09 AM, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
> I'm not sure what is "not acceptable" as it "totally breaks the error
> handling" in the above code.
> I assumed that you want to check that sscanf can read what sprintf generated
> when handling "\set". I'd guess that libc would be broken if it was the
> case. I've made pgbench check that it is not.
If the variable contains something that is not an integer, the
existing code will end up here:
fprintf(stderr, "invalid input syntax for integer: \"%s\"\n", str);
With your patch, you get different behavior depending on exactly how
the input is malformed. I have a strong suspicion you're going to
tell me that this is another one of those cases where it's OK to make
the error handling worse than it is today, but I'm tired of arguing
that point. I'm not going to commit it this way, and frankly, neither
is anyone else.
The Enterprise PostgreSQL Company
|Next Message||Gilles Darold||2016-03-09 17:32:08||Patch to implement pg_current_logfile() function|
|Previous Message||Tomas Vondra||2016-03-09 17:21:42||Re: multivariate statistics v14|