Thread: Make LANGUAGE SQL the default

Make LANGUAGE SQL the default

From
Peter Eisentraut
Date:
A sub-patch extracted from the bigger patch in thread "SQL-standard 
function body"[0]: Make LANGUAGE SQL the default in CREATE FUNCTION and 
CREATE PROCEDURE, per SQL standard.

[0]: 
https://www.postgresql.org/message-id/flat/1c11f1eb-f00c-43b7-799d-2d44132c02d7@2ndquadrant.com

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment

Re: Make LANGUAGE SQL the default

From
Tom Lane
Date:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> A sub-patch extracted from the bigger patch in thread "SQL-standard 
> function body"[0]: Make LANGUAGE SQL the default in CREATE FUNCTION and 
> CREATE PROCEDURE, per SQL standard.

I'm suspicious of doing this, mainly because DO does not have that
default.  I think sticking with no-default is less likely to cause
confusion.  Moreover, I don't really believe that having a default value
here is going to add any noticeable ease-of-use for anyone.  What's much
more likely to happen is that we'll start getting novice questions about
whatever weird syntax errors you get when trying to feed plpgsql code to
the sql-language function parser.  (I don't know what they are exactly,
but I'll bet a very fine dinner that they're less understandable to a
novice than "no language specified".)

I don't see any reason why we can't figure out that an unquoted function
body is SQL, while continuing to make no assumptions about a body written
as a string.  The argument that defaulting to SQL makes the latter case
SQL-compliant seems pretty silly anyway.

I also continue to suspect that we are going to need to treat quoted
and unquoted SQL as two different languages, possibly with not even
the same semantics.  If that's how things shake out, claiming that the
quoted-SQL version is the default because spec becomes even sillier.

            regards, tom lane



Re: Make LANGUAGE SQL the default

From
Pavel Stehule
Date:


so 10. 10. 2020 v 18:14 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> A sub-patch extracted from the bigger patch in thread "SQL-standard
> function body"[0]: Make LANGUAGE SQL the default in CREATE FUNCTION and
> CREATE PROCEDURE, per SQL standard.

I'm suspicious of doing this, mainly because DO does not have that
default.  I think sticking with no-default is less likely to cause
confusion.  Moreover, I don't really believe that having a default value
here is going to add any noticeable ease-of-use for anyone.  What's much
more likely to happen is that we'll start getting novice questions about
whatever weird syntax errors you get when trying to feed plpgsql code to
the sql-language function parser.  (I don't know what they are exactly,
but I'll bet a very fine dinner that they're less understandable to a
novice than "no language specified".)

I don't see any reason why we can't figure out that an unquoted function
body is SQL, while continuing to make no assumptions about a body written
as a string.  The argument that defaulting to SQL makes the latter case
SQL-compliant seems pretty silly anyway.

+1

Pavel


I also continue to suspect that we are going to need to treat quoted
and unquoted SQL as two different languages, possibly with not even
the same semantics.  If that's how things shake out, claiming that the
quoted-SQL version is the default because spec becomes even sillier.

                        regards, tom lane