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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] [COMMITTERS] pgsql: Fix hard-coded relkind constants in pg_dump.c.
Дата
Msg-id 7781.1489111146@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] [COMMITTERS] pgsql: Fix hard-coded relkind constants in pg_dump.c.  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: [HACKERS] [COMMITTERS] pgsql: Fix hard-coded relkind constants in pg_dump.c.  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
Michael Paquier <michael.paquier@gmail.com> writes:
> On Fri, Mar 10, 2017 at 9:19 AM, Tom Lane <tgl@sss.pgh.pa.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] [PATCH] Teach Catalog.pm how many attributes thereshould be per DATA() line
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: [HACKERS] on_dsm_detach() callback and parallel tuplesort BufFile resource management