Re: Updated CREATE FUNCTION syntax

"Joel Burton" <joel(at)joelburton(dot)com> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> said:
>> ISTM the reason we've not addressed this for so long is that no one
>> could think of a reasonable way to solve it on the backend side.
>> Maybe we just have to shift our focus.

> Out of curiosity, Tom, why the preference for a solution like this
> rather than allowing for a much-less-common-than-' delimiter for the
> create function syntax? (Such as the "[[" and "]]" I suggested a few
> posts ago?)

That's not a solution for psql, unless you also teach psql about these
delimiters --- else it'll still terminate the query shipped to the
backend too soon. That being the case, you might as well just implement
the delimiters in psql. Seems like [[ and ]] are isomorphic to what I
suggested. I'd have a preference for \[ and \] though.

Note that I did not mean to suggest that "\beginliteral" and
"\endliteral" were actually the names I'd want to use; that was just
for clarity of exposition. Something shorter would be more practical.
It might be reasonable to use \' for example, or if that seems a little
too brief, \lit and \eol (end literal), or \lit ... \til if you remember
Algol68.

> That would have the advantage of being consistent as users switched
> from writing functions in psql to writing function-writing functions,
> to writing functions in other environments, etc.

I would expect script-ish environments to follow psql's lead. For
GUI-ish environments this is probably a complete nonissue; I'd pretty
much expect the function body to pop up in a separate editing window
to start with, so that the user really has no need to think about
separating the function body from the rest of the CREATE FUNCTION
command.

In any case I do not think it's likely that client-side programming
environments would be able to take advantage of such a feature without
rework, just as psql couldn't. Any backend-side solution we might put
in would really amount to a protocol change, whether you wanted to call
it one or not. So the notion of "fix it once in the backend, not once
per client" seems illusory to me for this particular problem.

regards, tom lane