Re: massive quotes?

Can we add digits to the allowed character set of the marker? It'd make 
life easier for languages that check if the quoting marker actually 
occurs in the text to be quoted.


Jan

Tom Lane wrote:

> 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 form
>     dollarsign 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
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #