Re: massive quotes?

Sean Chittenden <sean@chittenden.org> writes:
> Using $$[.*]\n as a lexical token is a quasi-problematic as the anchor
> is the newline, something that SQL has been free of for as long as I'm
> aware of.  By using a static lexical token, such as @@, newline's
> aren't important, thus reducing the number of accidental syntax errors
> from programmers.  While I abhor the "let's put a magic token in this
> context to handle this quirk" grammar design methodology that Perl has
> brought, I do think that a simple doubling up of a nearly unused
> operator would be sufficient, concise, and easy.

No, it absolutely would not be.  We could pick something that would not
create conflicts as a quote start marker, since we know what the SQL
grammar is.  But it would be guaranteed to fail as an end marker.  Let
me remind you that the goal here is to be able to quote any text
whatever, including nested uses of the same quoting mechanism.

After sleeping on it, I do think that tying the mechanism to newlines
is just unnecessary complication.  I'm currently leaning to an idea that
was suggested yesterday by (I think) Andreas: let the quote start marker
be a token of the formdollarsign zero-or-more-letters dollarsign
and let the quote body extend to the next occurrence of the identical
string.  For example... $Q$Joe's house$Q$ ...
is equivalent to... 'Joe''s house' ...

This is extremely compact for quoting strings that don't contain any
doubled dollar signs, since you don't need any letters at all.  I could
see $$text$$ becoming a very common way to quote material that contains
single quotes or backslashes.  But since you can choose any string of
letters to make up the terminating token, the mechanism is able to quote
any text whatever, including nested occurrences of the same structure
(with a different letterstring of course).

Note that there is no particular need to insist on any nearby newlines.
If the construct is written just following an identifier or keyword,
then you do need some intervening whitespace to keep the $Q$ from being
read as part of that identifier, but I doubt this will bother anyone.

Note that I'm allowing only letters, not digits, in the string; this
avoids any possible ambiguity with $n parameter tokens.  We have no
other SQL tokens that are allowed to start with $, so this creates no
other lexical ambiguity.

Comments?
        regards, tom lane