On 03/04/2015 09:42 AM, Tom Lane wrote:
Peter Eisentraut <pete...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
