Re: Proposal: new border setting in psql - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Proposal: new border setting in psql
Date
Msg-id Pine.GSO.4.64.0901081829530.2578@westnet.com
Whole thread Raw
In response to Re: Proposal: new border setting in psql  ("D'Arcy J.M. Cain" <darcy@druid.net>)
Responses Re: Proposal: new border setting in psql  ("D'Arcy J.M. Cain" <darcy@druid.net>)
List pgsql-hackers
On Thu, 8 Jan 2009, D'Arcy J.M. Cain wrote:

> On Thu, 8 Jan 2009 13:51:44 -0500 (EST)
> Greg Smith <gsmith@gregsmith.com> wrote:
>>
>> A. Einstein was a really smart dude.
> Which character in the above example would you escape.

"." is on the long list of characters to be escaped I sent out earlier. 
The parser looks for all sorts of enumeration syntaxes--A., I), (IV)--but 
they all require some punctuation which makes those characters the ones to 
focus on.

> I would suggest that if we want actual ReST-safe output we should create 
> a "border = 4" setting.  The code changes would be minimal.  All we need 
> to do is check for a value of 4 in addition to checking whether escaping 
> is necessary.

This seems like a reasonable spec to me.  If you just want that general 
format, you can get that and may very well end up with something that's 
useful ReST anyway with the border=3 mode your existing patch implements. 
As you demonstrated, there are several situations where a character you 
think might do something special turns out to be ignored, with "\" being 
the most likely to cause trouble.

If you really want something that will be valid ReST, use border=4, which 
adds escaping for everything inside the table that's on that long list of 
potential markup characters.  That's going to make the table look quite 
ugly if you have many characters on the escape list, but I don't see any 
way to get around that without a heavy dependency on behavior that's only 
documented in the docutils implementation itself.  The "spec" itself is 
really more of a user guide, and it sure isn't good enough to let you know 
every case where special characters may be interpreted as markup.  As 
demonstrated with the Einstein example, you sometimes need a while line of 
lookahead to figure that out anyway, which makes a smarter escaping 
solution pretty hard to implement.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD


pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: Improving compressibility of WAL files
Next
From: KaiGai Kohei
Date:
Subject: Re: New patch for Column-level privileges