Re: Proposal: new border setting in psql

On Thu, 8 Jan 2009 18:45:43 -0500 (EST)
Greg Smith <gsmith(at)gregsmith(dot)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 tried escaping the '.' but it didn't change the behaviour.

> > 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.

Enter the following into my test rig http://www.druid.darcy/rest.py:

+----+--------+
| id | name |
+====+========+
| 8 | T'est |
+----+--------+
| 9 | T*est |
+----+--------+
| 10 | T\est |
+----+--------+
| 11 | T\\est |
+----+--------+
| 12 | T_est |
+----+--------+
| 13 | T`est |
+----+--------+

Notice that only the backslash needs to be escaped. However, if you
just add the backslash it won't work because the table will be
malformed. You need to widen every other field as well.

As Tom has pointed out, ReST has problems beyond our implementation.
People who use it are aware of these warts. Given that I really think
that the cleanest solution is to just give them "border 3", don't
mention ReST in the docs and have it happily work for 95% of the cases
in a ReST processor.

How about my other proposal under the "Output filter for psql"
subject? That would let people create parsers as safe as they need
them. I think that this proposal is still useful for those that need
something quick and dirty though.

--
D'Arcy J.M. Cain <darcy(at)druid(dot)net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.