Greg Stark <st...@mit.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers