Re: Bootstrap DATA is a pita

On 03/04/2015 09:42 AM, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> On 3/3/15 9:49 PM, Robert Haas wrote:
>>> Even this promises to vastly increase the number of lines in the file,
>> I think lines are cheap.  Columns are much harder to deal with.
> Yeah.  pg_proc.h is already impossible to work with in a standard
> 80-column window.  I don't want to find that the lines mostly wrap even
> when I expand my editor window to full screen width, but that is certainly
> what will happen if we adopt column labelling *and* insist that entries
> remain all on one line.  (As a data point, the maximum usable Emacs window
> width on my Mac laptop seems to be about 230 characters.)
>
> It's possible that gaining the ability to depend on per-column defaults
> would reduce the typical number of fields so much that pg_proc.h entries
> would still fit on a line of 100-some characters ... but I'd want to see
> proof before assuming that.  And pg_proc isn't even our widest catalog.
> Some of the ones that are wider, like pg_am, don't seem like there would
> be any scope whatsoever for saving space with per-column defaults.
>
> So while I can see the attraction of trying to fit things on one line,
> I doubt it's gonna work very well.  I'd rather go over to a
> one-value-per-line format and live with lots of lines.
>
>

Is it necessarily an all or nothing deal?

Taking a previous example, we could have something like:
    {         oid => 2249,  oiddefine => 'CSTRINGOID',  typname => 'cstring',         typlen => -2, typbyval => 1,
  ...    }
 

which would allow us to fit within a reasonable edit window (for my 
normal window and font that's around 180 characters) and still reduce 
the number of lines.

I'm not wedded to it, but it's a thought.

cheers

andrew