Make LANGUAGE SQL the default
A sub-patch extracted from the bigger patch in thread "SQL-standard
function body"[0]/messages/by-id/1c11f1eb-f00c-43b7-799d-2d44132c02d7@2ndquadrant.com: Make LANGUAGE SQL the default in CREATE FUNCTION and
CREATE PROCEDURE, per SQL standard.
[0]: /messages/by-id/1c11f1eb-f00c-43b7-799d-2d44132c02d7@2ndquadrant.com
/messages/by-id/1c11f1eb-f00c-43b7-799d-2d44132c02d7@2ndquadrant.com
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:
0001-Make-LANGUAGE-SQL-the-default.patchtext/plain; charset=UTF-8; name=0001-Make-LANGUAGE-SQL-the-default.patch; x-mac-creator=0; x-mac-type=0Download
From f1cd36936ef18acda92258edecaeb4d0b83adea9 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter@eisentraut.org>
Date: Sat, 10 Oct 2020 10:45:02 +0200
Subject: [PATCH] Make LANGUAGE SQL the default
LANGUAGE SQL is the default in CREATE FUNCTION and CREATE PROCEDURE,
per SQL standard.
---
doc/src/sgml/ref/create_function.sgml | 5 +++--
doc/src/sgml/ref/create_procedure.sgml | 5 +++--
src/backend/commands/functioncmds.c | 11 ++---------
src/test/regress/expected/create_function_3.out | 4 ++--
src/test/regress/sql/create_function_3.sql | 4 ++--
5 files changed, 12 insertions(+), 17 deletions(-)
diff --git a/doc/src/sgml/ref/create_function.sgml b/doc/src/sgml/ref/create_function.sgml
index 3c1eaea651..79753e3454 100644
--- a/doc/src/sgml/ref/create_function.sgml
+++ b/doc/src/sgml/ref/create_function.sgml
@@ -257,8 +257,9 @@ <title>Parameters</title>
The name of the language that the function is implemented in.
It can be <literal>sql</literal>, <literal>c</literal>,
<literal>internal</literal>, or the name of a user-defined
- procedural language, e.g., <literal>plpgsql</literal>. Enclosing the
- name in single quotes is deprecated and requires matching case.
+ procedural language, e.g., <literal>plpgsql</literal>. The default is
+ <literal>sql</literal>. Enclosing the name in single quotes is
+ deprecated and requires matching case.
</para>
</listitem>
</varlistentry>
diff --git a/doc/src/sgml/ref/create_procedure.sgml b/doc/src/sgml/ref/create_procedure.sgml
index e258eca5ce..a2b20e989c 100644
--- a/doc/src/sgml/ref/create_procedure.sgml
+++ b/doc/src/sgml/ref/create_procedure.sgml
@@ -162,8 +162,9 @@ <title>Parameters</title>
The name of the language that the procedure is implemented in.
It can be <literal>sql</literal>, <literal>c</literal>,
<literal>internal</literal>, or the name of a user-defined
- procedural language, e.g., <literal>plpgsql</literal>. Enclosing the
- name in single quotes is deprecated and requires matching case.
+ procedural language, e.g., <literal>plpgsql</literal>. The default is
+ <literal>sql</literal>. Enclosing the name in single quotes is
+ deprecated and requires matching case.
</para>
</listitem>
</varlistentry>
diff --git a/src/backend/commands/functioncmds.c b/src/backend/commands/functioncmds.c
index c3ce480c8f..1fafb29377 100644
--- a/src/backend/commands/functioncmds.c
+++ b/src/backend/commands/functioncmds.c
@@ -797,17 +797,9 @@ compute_function_attributes(ParseState *pstate,
*as = NIL; /* keep compiler quiet */
}
+ /* process optional items */
if (language_item)
*language = strVal(language_item->arg);
- else
- {
- ereport(ERROR,
- (errcode(ERRCODE_INVALID_FUNCTION_DEFINITION),
- errmsg("no language specified")));
- *language = NULL; /* keep compiler quiet */
- }
-
- /* process optional items */
if (transform_item)
*transform = transform_item->arg;
if (windowfunc_item)
@@ -962,6 +954,7 @@ CreateFunction(ParseState *pstate, CreateFunctionStmt *stmt)
get_namespace_name(namespaceId));
/* Set default attributes */
+ language = "sql";
isWindowFunc = false;
isStrict = false;
security = false;
diff --git a/src/test/regress/expected/create_function_3.out b/src/test/regress/expected/create_function_3.out
index ce508ae1dc..e0a7715c56 100644
--- a/src/test/regress/expected/create_function_3.out
+++ b/src/test/regress/expected/create_function_3.out
@@ -14,11 +14,11 @@ SET search_path TO temp_func_test, public;
--
-- ARGUMENT and RETURN TYPES
--
-CREATE FUNCTION functest_A_1(text, date) RETURNS bool LANGUAGE 'sql'
+CREATE FUNCTION functest_A_1(text, date) RETURNS bool LANGUAGE SQL
AS 'SELECT $1 = ''abcd'' AND $2 > ''2001-01-01''';
CREATE FUNCTION functest_A_2(text[]) RETURNS int LANGUAGE 'sql'
AS 'SELECT $1[1]::int';
-CREATE FUNCTION functest_A_3() RETURNS bool LANGUAGE 'sql'
+CREATE FUNCTION functest_A_3() RETURNS bool
AS 'SELECT false';
SELECT proname, prorettype::regtype, proargtypes::regtype[] FROM pg_proc
WHERE oid in ('functest_A_1'::regproc,
diff --git a/src/test/regress/sql/create_function_3.sql b/src/test/regress/sql/create_function_3.sql
index bd108a918f..7515ae080a 100644
--- a/src/test/regress/sql/create_function_3.sql
+++ b/src/test/regress/sql/create_function_3.sql
@@ -20,11 +20,11 @@ CREATE SCHEMA temp_func_test;
--
-- ARGUMENT and RETURN TYPES
--
-CREATE FUNCTION functest_A_1(text, date) RETURNS bool LANGUAGE 'sql'
+CREATE FUNCTION functest_A_1(text, date) RETURNS bool LANGUAGE SQL
AS 'SELECT $1 = ''abcd'' AND $2 > ''2001-01-01''';
CREATE FUNCTION functest_A_2(text[]) RETURNS int LANGUAGE 'sql'
AS 'SELECT $1[1]::int';
-CREATE FUNCTION functest_A_3() RETURNS bool LANGUAGE 'sql'
+CREATE FUNCTION functest_A_3() RETURNS bool
AS 'SELECT false';
SELECT proname, prorettype::regtype, proargtypes::regtype[] FROM pg_proc
WHERE oid in ('functest_A_1'::regproc,
--
2.28.0
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
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
Show quoted text
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