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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
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 01:59:06
Message-ID: 7781.1489111146@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Peter Eisentraut 2017-03-10 02:06:50 Re: pgsql: Create INSTALL file via XSLT
Previous Message Tom Lane 2017-03-10 01:46:15 pgsql: Fix portability problem in Catalog.pm.

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2017-03-10 02:02:40 Re: on_dsm_detach() callback and parallel tuplesort BufFile resource management
Previous Message Robert Haas 2017-03-10 01:57:05 Re: [PATCH] Teach Catalog.pm how many attributes there should be per DATA() line