Re: BUG #12379: pgbench should hint to pgbench -i - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #12379: pgbench should hint to pgbench -i
Date
Msg-id 11036.1437237151@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #12379: pgbench should hint to pgbench -i  (Julien Rouhaud <julien.rouhaud@dalibo.com>)
Responses Re: BUG #12379: pgbench should hint to pgbench -i  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-bugs
Julien Rouhaud <julien.rouhaud@dalibo.com> writes:
> On 18/07/2015 13:49, Fabien COELHO wrote:
>> I'm wondering why you added the define. Isn't-there some convenient
>> include to get errcode definitions?

> IIRC correctly, you have to include postgres.h for that.  I supposed it
> was better to define it than adding such an include, since it shouldn't
> change and it's already done like this in vacuumdb.c.

Frontend code *mustn't* include postgres.h.

You could imagine including errcodes.h by itself after supplying a
suitable definition for MAKE_SQLSTATE(); but I think you'd want it to
reconstitute the five characters into a string literal, and I'm not
sure that there's any easy way to do that in C.  If we wanted to
go in this direction, it might be easier to create another Perl
script that puts out an errcodes-fe.h with the errcode symbols
#defined as string literals.

The larger reason we've not done this is that, once a given errcode
is wired into some client-side code, it effectively becomes part of
the protocol and can't be reassigned.  See the comments around the
places in libpq where specific errcodes are referenced.  So it's
not very clear that we want to encourage frontend code to use this
technique a lot.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: BUG #12379: pgbench should hint to pgbench -i
Next
From: Tom Lane
Date:
Subject: Re: BUG #13490: Segmentation fault on pg_stat_activity