Re: Proposal: new border setting in psql

On Mon, 12 Jan 2009, D'Arcy J.M. Cain wrote:

> 0. Drop this patch
> 1. Call it Rest and make it 100% compliant
> 2. Call it Rest-like
> 3. Call it simply border level 3

Every time I play with this for a minute or two, I'm able to find some
real-world data that completely breaks the ReST compatibility of your
"border level 3" implementation in short order. I've been on the lookout
for them lately and they're not hard to find.

Since ReST compatibility was the only interesting part to me, that knocks
(3) off my list. Obviously I like the idea and don't want (0).

What I would suggest is reasonable is a hybrid of the two remaining ones:

4. Call it Rest-like and make it compliant with all the reasonable cases

If there is anything really hideous in the spec that's extremely difficult
to avoid accidentally tripping over without making the code really
complicated (the non-ASCII bullet stuff I mentioned comes to mind), those
we can just document as known limitations of ReST-like mode and move
along. Anybody who uses ReST regularly knows how easy it is to
accidentally inject things that are interpreted as market, and I don't
think that will be viewed as a PostgreSQL fault as long as there's a good
effort to escape around the most common markup failure situations. It's
not like there's a proper spec to conform against here anyway.

Alvaro suggests the aligned mode code path could be re-used here to find
the widths of the escaped cells, that sounds like a useful way to handle
the "escape all punctuation" pass I proposed.

Cedric expressed some concern that this result would be ugly, and that
basically he'd rather hand-edit it with the minimal escaping required
instead. I'd say turn that around: output an ugly but functional bit of
ReST, and if somebody wants to try removing some escapes to make it
prettier the onus is on them to try that without breaking things.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD