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