Re: massive quotes?

Jon Jensen <jon@endpoint.com> writes:
> On Sat, 13 Sep 2003, Miko O'Sullivan wrote:
>> In Perl, the rule for here docs is NOT "it starts immediately after
>> the definition of the terminator" (as in your example).  The rule is
>> "it starts on the first line after the end of the command in which the
>> terminator appears".  There's a very good reason for this distinction.
>> That reason is that it allows the command to be succinct, usually a
>> single line, and the here doc stays completely separate.

> I'm aware of that distinction, and use it to advantage in Perl. It would 
> make parsing harder, though.

Both Perl and shell are designed around the idea that most commands
should fit on one line, so it makes sense for them to do things that
way.  I think SQL commands run to more than one line as often as not,
so I'm not really enamored of keeping the next-line behavior of here
documents for our purposes.  Think of
CREATE FUNCTION foo(int, text, ...) RETURNS text AS $BODY$LANGUAGE plpgsql IMMUTABLE RETURNS NULL ON NULL INPUT;...
functiontext ...$BODY$
 

This is not lexing any more, it is some kind of weird
action-at-a-distance interpretation of what you type.  To understand it
you have to match up the occurrence of $BODY$ with the later occurrence
of a semicolon.  And what happens if you don't want to type a semicolon?
(For instance, in psql you might be wanting to use \g instead.)

The other alternative is "it starts on the next physical line":
CREATE FUNCTION foo(int, text, ...) RETURNS text AS $BODY$... function text ...$BODY$LANGUAGE plpgsql IMMUTABLE RETURNS
NULLON NULL INPUT;
 

which is probably more workable from an implementation point of view,
but it really doesn't seem to offer any notational advantage over just
letting the quoted text start where the quote marker is.

A more principled argument is that SQL syntax is generally not dependent
on newlines and we shouldn't make it so.  The original here-document
design made sense in the context of shell scripts, wherein newlines
definitely do have syntactic meaning.  The fact that Perl picked it up
without changing it doesn't impress me a lot --- Larry Wall's taste in
lexical design is, um, eclectic, but not necessarily something to emulate.

> In the end it looks like consensus has settled on a new syntax with some 
> of the benefits of here documents without the requirement that the end 
> token be on its own blank line (and thus necessitating end-of-line checks) 
> and perhaps more importantly, not requiring that everything quoted in a 
> here document always end with a newline.

Yeah, one thing I like about the dollar-quoting proposal is you can
easily control whether there are leading or trailing newlines in the
string.  This is not very important for function definitions, but it
makes the feature a lot more useful for other quoted strings.
        regards, tom lane