Neil Padgett <npadgett@redhat.com> writes:
> I've just read the relevant messages. Though, I do find the list
> archives a bit slow for any useful browsing -- can I grab a copy of them
> from somewhere? Setting up a mirror might be an idea. . .
The raw archives are under http://www.ca.postgresql.org/mhonarc/
in monthly files, for example
http://www.ca.postgresql.org/mhonarc/pgsql-patches/archive/pgsql-patches.200108
I am not sure whether our mirror sites mirror them or not. In any case,
you should talk to Marc if you want to coordinate some sort of long-term
mirroring arrangement.
> Can you cite a client which does not use a fixed-width font at this
> time? I think most I've worked with use one for SQL interaction -- it is
> pretty much "the way things are done."
I'd believe that data is entered/displayed in fixed-width text; I'm less
ready to assume that for error messages, however.
>> (b) it becomes essentially useless when the input query exceeds a few
>> lines in size.
> How so? I grab out the line of interest when reporting the error.
My apologies, I missed that aspect of your patch. An interesting
solution. However, it doesn't handle embedded tabs, and there is still
the objection that a client app might want to present the location info
in a completely different fashion anyway.
>> The conclusion we had come to in previous discussion is that the error
>> offset ought to be delivered to the client application as a separate
>> component of the error report,
> Well, perhaps the error message could be changed to something like this,
> with a special string marking the parse error position?
> test=# SELECT * FRUM bob;
> ERROR: parser: parse error at or near 'frum':
> SELECT * ***FRUM bob;
I was thinking something along the lines of
ERROR: message string just like now
POSITION: 42
OTHERSTUFF: yadda yadda
ie, the error message string is now interpreted as keyworded lines,
somewhat like (say) mail headers. This would be workable for new
clients, wouldn't break anything at the wire-protocol level, and would
not be totally useless if presented "raw" to a user by an old client.
See the archives for more info --- I think the last discussion was three
or four months back when Peter E. started to make noises about fixing
elog for internationalization.
regards, tom lane
