Re: Bizarre choice of case for RELKIND_PARTITIONED_TABLE
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-03-07T19:25:55Z
Lists: pgsql-hackers
On Tue, Mar 7, 2017 at 12:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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
> ---------
> r
> t
> P
> v
> m
> i
> S
> c
> (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.
I can't muster a lot of outrage about this one way or another. One
possible advantage of 'P' is that there are fewer places where 'P' is
mentioned in the source code than 'p'.
[rhaas pgsql]$ git grep "'p'" | wc -l
293
[rhaas pgsql]$ git grep "'P'" | wc -l
104
...so it's a little easier to pick out the cases that are talking
about partitioned tables than it would be with a lower case letter.
However, as I say, I don't care very much.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Commits
-
Change the relkind for partitioned tables from 'P' to 'p'.
- 8b358b42f8eb 10.0 landed
-
Fix hard-coded relkind constants in assorted other files.
- 9c2635e26f6f 10.0 landed
-
Fix hard-coded relkind constants in assorted src/bin files.
- fcd778eb703c 10.0 landed
-
Fix hard-coded relkind constants in psql/describe.c.
- 395bfaae8e78 10.0 landed
-
Fix hard-coded relkind constants in pg_dump.c.
- fe797b4a6a69 10.0 landed
-
Restructure LOCKTAG as per discussions of a couple months ago.
- 3a694bb0a16f 8.1.0 cited