Re: BUG #12379: pgbench should hint to pgbench -i
От | Tom Lane |
---|---|
Тема | Re: BUG #12379: pgbench should hint to pgbench -i |
Дата | |
Msg-id | 11036.1437237151@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #12379: pgbench should hint to pgbench -i (Julien Rouhaud <julien.rouhaud@dalibo.com>) |
Ответы |
Re: BUG #12379: pgbench should hint to pgbench -i
|
Список | 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 по дате отправления: