Re: [HACKERS] [COMMITTERS] pgsql: Fix hard-coded relkind constants in pg_dump.c.
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] [COMMITTERS] pgsql: Fix hard-coded relkind constants in pg_dump.c. |
Дата | |
Msg-id | CAB7nPqSOHzkEHNbksiSQNSnVNkj4yPAh6RvnOtAsvJLOUp_AMg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [COMMITTERS] pgsql: Fix hard-coded relkind constants in pg_dump.c. (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Fri, Mar 10, 2017 at 10:59 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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. Yes, I just noticed postgres_fdw as well... -- Michael
В списке pgsql-hackers по дате отправления: