Re: [COMMITTERS] pgsql: Fix hard-coded relkind constants in pg_dump.c.

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Fix hard-coded relkind constants in pg_dump.c.
Date: 2017-03-10 02:18:24
Message-ID: CAB7nPqSOHzkEHNbksiSQNSnVNkj4yPAh6RvnOtAsvJLOUp_AMg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Fri, Mar 10, 2017 at 10:59 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
>> On Fri, Mar 10, 2017 at 9:19 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Existing style is mostly to inject relkind values into constructed
>>> query strings using %c. I did not bother to touch places that did it
>>> like that, but really a better technique is to stringify the RELKIND
>>> macro, at least in places where you'd want single quotes around the
>>> code character. That avoids any runtime effort and keeps the RELKIND
>>> symbol close to where it's used.
>
>> I have been wondering about the lack of readability with those
>> hardcoded relkinds in the code for some time but... Wouldn't it be
>> better to change as well psql's describe.c and tab_complete.c, as well
>> as pg_upgrade and initdb code?
>
> Yup, working on it.
>
> There's a fair number of other fields that could stand the same treatment,
> but for now I'm just going to touch references to relkind.

Yes, I just noticed postgres_fdw as well...
--
Michael

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Alvaro Herrera 2017-03-10 03:09:32 Re: pgsql: Fix pgbench's failure to honor the documented long-form option "
Previous Message Peter Eisentraut 2017-03-10 02:06:50 Re: pgsql: Create INSTALL file via XSLT

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-03-10 02:25:31 Re: on_dsm_detach() callback and parallel tuplesort BufFile resource management
Previous Message Robert Haas 2017-03-10 02:18:19 Re: on_dsm_detach() callback and parallel tuplesort BufFile resource management