[HACKERS] Bizarre choice of case for RELKIND_PARTITIONED_TABLE - Mailing list pgsql-hackers

From Tom Lane
Subject [HACKERS] Bizarre choice of case for RELKIND_PARTITIONED_TABLE
Date
Msg-id 27899.1488909319@sss.pgh.pa.us
Whole thread Raw
Responses Re: [HACKERS] Bizarre choice of case for RELKIND_PARTITIONED_TABLE  (Robert Haas <robertmhaas@gmail.com>)
Re: [HACKERS] Bizarre choice of case for RELKIND_PARTITIONED_TABLE  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Re: [HACKERS] Bizarre choice of case for RELKIND_PARTITIONED_TABLE  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Re: [HACKERS] Bizarre choice of case for RELKIND_PARTITIONED_TABLE  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Is there a good reason why RELKIND_PARTITIONED_TABLE is 'P' not 'p'?
It looks rather out of place considering that seven of the eight
pre-existing relkind codes are lower case.  (And no, I don't especially
approve of RELKIND_SEQUENCE being 'S' either, but it's far too late to
change that.)  Also, in typical low-res monospaced fonts, there's nearly
no difference except vertical alignment between P and p, meaning that in
something like

regression=# select distinct relkind from pg_class;relkind 
---------rtPvmiSc
(8 rows)

you have to look rather closely even to notice that what you're seeing
isn't in the case you might expect.

I think we should change this while we still can.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Partitioned tables and relfilenode
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Poor memory context performance in large hash joins