Jan
Tom Lane wrote:
Sean Chittenden <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED])
-- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
