Re: Re: Do we need use more meaningful variables to replace 0 in catalog head files?

Greg Stark <stark(at)mit(dot)edu> writes:
> Just throwing this out there....

> It would be neat if the file format was precisely a tab or comma
> separated file suitable for loading into the appropriate table with
> COPY or loading into a spreadsheet.

Actually, I'd say that's a very accurate description of what we DO NOT
want. That has all of the disadvantages of the DATA-line format, and
more besides, namely that we don't even get any macro-substitution-like
abilities. The right way to think about this, IMO, is that we want to
abstract the representation as much as we easily can. We definitely
need a concept of default values for omitted columns, and we need at least
some limited ability to insert symbolic values that will be resolved at
compile or initdb time (see FLOAT8PASSBYVAL and PGUID for existing
examples in that line). And we want symbolic representations for OID
references, whether the associated column is declared as reg-something
or just a plain OID column. (I don't want to end up having to invent
a reg-something type for every system catalog, so the idea that was
mentioned upthread of having that be driven off the declared column
type seems like a nonstarter to me, even if we were willing to take
the compatibility hit of changing the declared column types of a lot
of system catalog columns.)

Now, some of that could be gotten by brute force in a CSV-type file
format, but I do not see how replacing

DATA(insert OID = 1242 ( boolin PGNSP PGUID 12 1 0 0 0 f f f f t f i s 1 0 16 "2275" _null_ _null_ _null_ _null_ _null_ boolin _null_ _null_ _null_ ));

with

1242,boolin,PGNSP,PGUID,internal,1,0,0,0,f,f,f,f,t,f,i,s,1,0,bool,{cstring},,,,,,boolin,,,

is any real improvement --- it certainly isn't making it any more readily
editable --- and replacing most of those fields with some spelling of
"default" isn't much better.

I follow the point about wishing that you could do bulk transformations in
some kind of SQL environment, but I think that direction leads to the same
sort of fruitless discussions we've had about adopting tooling for images
in the SGML docs. Namely that any tooling you do like that is probably
going to have a hard time producing reproducible reductions to text form,
which is going to create issues when reviewing and when tracking git
changes. I think our reference representation needs to be what's in git,
not some theoretically-equivalent form in a database somewhere.

regards, tom lane