On Wed, Aug 18, 2021 at 10:21 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Anyway, this whole argument could be rendered moot if we could convert
> name to a variable-length type. That would satisfy *both* sides of
> the argument, since those who need long names could have them, while
> those who don't would see net reduction instead of growth in space usage.
Yeah it seems like the best way forward.
> Of course, this is far far easier said than done; else we would have
> done it years ago. But maybe it's not entirely out of reach.
> I do not think it'd be hard to change "name" to have the same on-disk
> storage representation as cstring; the hard part is what about its
> usage in fixed-width catalog structures. Maybe we could finesse that
> by decreeing that the name column always has to be the last
> non-CATALOG_VARLEN field. (This would require fixing up the couple of
> places where we let some other var-width field have that distinction;
> but I suspect that would be small in comparison to the other work this
> implies. If there are any catalogs having two name columns, one of them
> would become more difficult to reach from C code.)
Here is the list on some recent build (as of 17707c059c):
relname | array_agg
------------------+----------------------------------
pg_collation | {collname,collctype,collcollate}
pg_database | {datctype,datcollate,datname}
pg_event_trigger | {evtevent,evtname}
pg_subscription | {subname,subslotname}
pg_trigger | {tgname,tgnewtable,tgoldtable}
(5 rows)
> I wonder if we'd get complaints from changing the catalog column layouts
> that much. People are used to the name at the front, I think. OTOH,
> I expected a lot of bleating about the OID column becoming frontmost,
> but there hasn't been much.
I don't think that would be comparable. Having an extra oid in the
1st column doesn't really make a raw SELECT * harder to read. But
having the XXXname column way behind, and not even at the end, means
that most people will have to type an extra "xxxname," for each
throwaway query run to quickly verify something. I know that I often
do that, and while I could live with it I'd rather not have to do it.
