From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Markus Wanner <markus(at)bluegap(dot)ch> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: New patch for Column-level privileges |
Date: | 2009-01-04 17:49:32 |
Message-ID: | 25643.1231091372@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Markus Wanner <markus(at)bluegap(dot)ch> writes:
> Stephen Frost wrote:
>>> BTW: how are long constant strings expected to be formatted? Are those
>>> allowed to exceed 80 columns, or are they expected to be split like so
>>
>> Honestly, I think I've seen both done.
> Yeah, that's why I'm asking.
IMHO, the trouble with breaking up error strings like that is that it
can defeat attempts to grep the source for a particular error message.
(If you search for "foo bar baz", you won't find it if someone chose
to break the string between those words.) This isn't too harmful if
you get no hits, because you can try again with a substring --- but it
really sucks if some instances of the string are broken up differently
than others, because you might see only the wrong instances and come
to a mistaken conclusion about the possible sources of an error reported
from the field. So I tend not to like breaking up long strings at all,
and definitely look with disfavor on breaking them in random spots
rather than natural break points of the sentence.
Because of that, I tend not to worry about holding to the 80-column
window width when it comes to error message strings. Other than that
case, though, you should try to stay to less than 80 columns. If you
don't, pgindent will do it for you, and the end result will probably
be uglier than if you'd made the code fit manually.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-01-04 18:01:06 | Re: pg_stats queries versus per-database encodings |
Previous Message | Simon Riggs | 2009-01-04 17:44:21 | Re: parallel restore |