pgsql: Fix hard-coded relkind constants in pg_dump.c.
Fix hard-coded relkind constants in pg_dump.c.
Although it's reasonable to expect that most of these constants will
never change, that does not make it good programming style to hard-code
the value rather than using the RELKIND_FOO macros. There were only
a few such violations, and all relatively new AFAICT.
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.
Discussion: /messages/by-id/11145.1488931324@sss.pgh.pa.us
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/fe797b4a6a69ec0c9bf6ff992eac20c4084fda41
Modified Files
--------------
src/bin/pg_dump/pg_dump.c | 22 +++++++++++++---------
1 file changed, 13 insertions(+), 9 deletions(-)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On Fri, Mar 10, 2017 at 9:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Fix hard-coded relkind constants in pg_dump.c.
Although it's reasonable to expect that most of these constants will
never change, that does not make it good programming style to hard-code
the value rather than using the RELKIND_FOO macros. There were only
a few such violations, and all relatively new AFAICT.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?
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers