Can we use SQL to find out which keywords only mean something to Postgres inside a DO block or a PL/pgSQL function? And if not, can somebody perhaps tell me whether my list is complete or if there are words that shouldn't be on this list:
continue, exit, foreach, loop, return, return next, return query,
slice, while, alias, begin, constant, declare, exception, execute, get
(stacked) diagnostics, perform, raise, message, detail, hint, errcode,
debug, log, info, notice, warning, found, sqlerrm, sqlstate, new, old,
tg_name, tg_when, tg_level, tg_op, tg_relid, tg_relname,
tg_table_name, tg_table_schema, tg_nargs, tg_argv, tg_event, tg_tag
You can find the list in src/pl/plpgsql/src/pl_scanner.c:
Reserved keywords:
ALL
BEGIN
BY
CASE
DECLARE
ELSE
END
EXECUTE
FOR
FOREACH
FROM
IF
IN
INTO
LOOP
NOT
NULL
OR
STRICT
THEN
TO
USING
WHEN
WHILE
“Non-reserved” keywords:
ABSOLUTE
ALIAS
ARRAY
ASSERT
BACKWARD
CLOSE
COLLATE
COLUMN
COLUMN_NAME
CONSTANT
CONSTRAINT
CONSTRAINT_NAME
CONTINUE
CURRENT
CURSOR
DATATYPE
DEBUG
DEFAULT
DETAIL
DIAGNOSTICS
DUMP
ELSEIF
ELSIF
ERRCODE
ERROR
EXCEPTION
EXIT
FETCH
FIRST
FORWARD
GET
HINT
IMPORT
INFO
INSERT
IS
LAST
LOG
MESSAGE
MESSAGE_TEXT
MOVE
NEXT
NO
NOTICE
OPEN
OPTION
PERFORM
PG_CONTEXT
PG_DATATYPE_NAME
PG_EXCEPTION_CONTEXT
PG_EXCEPTION_DETAIL
PG_EXCEPTION_HINT
PRINT_STRICT_PARAMS
PRIOR
QUERY
RAISE
RELATIVE
RESULT_OID
RETURN
RETURNED_SQLSTATE
REVERSE
ROW_COUNT
ROWTYPE
SCHEMA
SCHEMA_NAME
SCROLL
SLICE
SQLSTATE
STACKED
TABLE
TABLE_NAME
TYPE
USE_COLUMN
USE_VARIABLE
VARIABLE_CONFLICT
WARNING
Special variables like TG_RELID or FOUND are not keywords, even though they play a special role in PL/pgSQL.
Related
We're attempting to run tests against a postgres function that returns a SETOF VARCHAR uppercase strings.
Whenever this test case runs, however, pgTap tries to look up a prepared statement with the same name as the uppercase value we're expecting to be returned. Is there any way of escaping this behaviour or calling this test case in another way to check output?
SELECT set_eq(
the_function_call(_property := 'value'),
$$ VALUES ('FIRST_RETURN'), ('SECOND_RETURN') $$,
'returns both expected values'
);
psql:/path/to/test.test.sql:20: ERROR: prepared statement "second_return" does not exist
CONTEXT: SQL statement "CREATE TEMP TABLE __taphave__ AS EXECUTE SECOND_RETURN"
I've tried backslashes, quotes, using UPPER on lowercase strings, casting the values as VARCHAR and ARRAY ['FIRST_RETURN', 'SECOND_RETURN'] as the second argument but still get the same prepared statement issue.
I was trying to avoid creating a prepared statement for each value that literally returns the same value again, but if that's the only way I guess I'll have to relent! Any help greatly appreciated.
Managed to get this working by changing the way the test is called;
SELECT set_eq(
$$ SELECT * FROM the_function_call(_property := 'value') $$,
ARRAY ['FIRST_RETURN', 'SECOND_RETURN'],
'returns both expected values'
);
Now passes with no issues
Why does using the IF statement in this function result in error 42601 [SQL0104], as shown below..? This is DB2-400 for i v7r3m0.
SQL Error [42601]: [SQL0104] Token <END-OF-STATEMENT> was not valid. Valid tokens: ;.
The code example I provide below executes without error until the IF statement is uncommented. I've tried moving the semicolons around and even removing them, but then the errors get worse and begin pointing to later statements being invalid.
I've checked the IBM documentation for IF on v7r3, and my syntax seems to be correct. Other code examples follow the same syntax as that and mine. I'm stumped.
CREATE OR REPLACE FUNCTION F_CERT.CERT_UPC_COMMON_DESC (UPC NUMERIC(14))
RETURNS INTEGER
LANGUAGE SQL
GLOBAL DETERMINISTIC
NO EXTERNAL ACTION
NOT FENCED
ALLOW PARALLEL
BEGIN
DECLARE RETVAL INTEGER DEFAULT 0 ;
DECLARE UPC_COUNT INTEGER DEFAULT 0 ;
DECLARE UPC_LIST CURSOR FOR
SELECT COUNT(*)
FROM F_CERTOB.BEERXT
WHERE BXUPCR=UPC
;
OPEN UPC_LIST ;
FETCH UPC_LIST INTO UPC_COUNT ;
CLOSE UPC_LIST ;
-- IF UPC_COUNT > 0 THEN
-- -- OTHER
-- -- COMMANDS
SET RETVAL = UPC_COUNT ;
-- END IF ;
RETURN RETVAL ;
END ;
SELECT F_CERT.CERT_UPC_COMMON_DESC (793936791660) AS C FROM SYSIBM.SYSDUMMY1 ;
EDIT:
Here is a second example; a trimmed-down version. As with the code above, everything is fine until the IF statements are uncommented:
CREATE OR REPLACE FUNCTION F_CERT.CERT_UPC_COMMON_DESC (UPC NUMERIC(14))
RETURNS INTEGER
LANGUAGE SQL
BEGIN
DECLARE RETVAL INTEGER DEFAULT 0 ;
-- IF 1=1 THEN
SET RETVAL = 1 ;
-- ELSE
SET RETVAL = 100 ;
-- END IF ;
RETURN RETVAL ;
END ;
SELECT F_CERT.CERT_UPC_COMMON_DESC (12345) AS C FROM SYSIBM.SYSDUMMY1 ;
I've continued searching since my OP, and I finally found the exact solution
here.
The issue is the statement delimiter. A conflict arises when the function contains flow-control and similarly structured statements that span multiple lines. In my code example, the compiler stops at END IF; and thinks that's all there is, instead of continuing to the END; of the function.
My SQL client is DBeaver 5.2.5, and it does have some functionality to run statements & scripts in different ways. This article gave me the idea to try running my CREATE script with the different actions of DBeaver, and I discovered I could make it work if I highlighted the whole script from CREATE to END but not including the trailing semicolon. Then I used Execute Statement {Ctrl+Enter} instead of the usual Execute Sctipt {Alt+X}. And it finally worked..!! But that seemed "kludgy" so I continued searching for a solution.
Then I found the imperfect, but perfectly acceptable solution in the main article mentioned above. I followed the directions to change the settings in my DBeaver client, and edited my code as shown below (notice the # characters). And then it finally worked..!! I could run the whole script, including the SELECT statement, and was able to do so with the usual Execute Statement {Alt+X} keystroke that I've become accustomed to.
CREATE OR REPLACE FUNCTION F_CERT.CERT_UPC_COMMON_DESC (UPC NUMERIC(14))
RETURNS INTEGER
LANGUAGE SQL
BEGIN
DECLARE RETVAL INTEGER DEFAULT 0;
IF 1=0 THEN
SET RETVAL = 1;
ELSE
SET RETVAL = 100;
END IF;
RETURN RETVAL;
END #
SELECT F_CERT.CERT_UPC_COMMON_DESC (793936791660) AS C FROM SYSIBM.SYSDUMMY1 #
I am brand new to PostgreSQL and I need someone to point me in
the right direction on how to write the results of a function to a text
file. Is it possible to do this within the PostgreSQL PL/pgSQL
language? I have done this before in Oracle using the UTL_FILE commands
and I was hoping that PostgreSQL had similar functionality. Thanks in advance for any help that you can give.
Kindly provide some examples of file operations.
CREATE OR REPLACE FUNCTION NP_AC015_FETCH.proc_log (P_MSG text, P_MODE integer default 1) RETURNS VOID AS $body$
DECLARE
V_F_IS_OPEN boolean; --IF LOG FILE IS ALREADY OPEN THIS IS SET TO TRUE
V_LOG_MSG varchar(32767); --LOG FILE NAME
V_LOG_DIR varchar(30) := 'ND_GANJIS_LOG_DIR'; --LOG DIRECOTY
vTemp UTL_FILE.FILE_TYPE;
BEGIN
select get_var('GM_LOG_FILE') INTO vTemp;
V_F_IS_OPEN := utl_file.is_open(vTemp);
if not V_F_IS_OPEN then
-- Log File Open
-- 32767 IS THE MAXIMUM NUMBER OF CHARACTERS PER LINE, INCLUDING THE NEWLINE CHARACTER, FOR THIS FILE.
vTemp := UTL_FILE.FOPEN(V_LOG_DIR, 'NIA_PLSQL_'||to_char(clock_timestamp(), 'yyyymmdd')||'.log', 'A', 32767);
end if;
-- LOG MSG TO BE WRITTEN TO THE LOG FILE
V_LOG_MSG := TO_CHAR(CURRENT_TIMESTAMP, 'yyyy/mm/dd hh24:mi:ss:ff3') ||' '|| P_MSG;
--Output messages to a file
UTL_FILE.PUT_LINE(vTemp, V_LOG_MSG);
--Closing Log File
if P_MODE = current_setting('NP_AC015_FETCH.PV_LOG_CLOSE_MODE')::pls_integer and utl_file.is_open(vTemp) then
utl_file.fclose(vTemp);
end if;
--HERE THE EXCEPTION PART IS NOT INCLUDED,
--Reason： PROGRAM WILL GO ON INFINITE LOOP IF SOME ERROR OCCURS HERE, BECAUSE, EACH EXCEPTION WRITES INTO
--LOG FILE, USING THIS PROCEDURE.
exception
when others then
RAISE EXCEPTION '%', dbms_utility.format_error_backtrace||chr(10)||dbms_utility.format_error_stack||chr(10)||dbms_utility.format_call_stack, true;
END;
$body$
LANGUAGE PLPGSQL;
You can install the adminpack contrib module and use the function pg_file_write(filename text, data text, append boolean).
Note that this function is restricted to superusers, but you can create a SECURITY DEFINER function owned by a superuser that provides the necessary functionality to the users you choose.
Fairly new to DB2 sql, so forgive my ignorance :)
I have a trigger with a condition inside. I want to then insert some params depending on the condition.. Here it is:
I've looked at DB2 documentation for triggers and also for if statements, and at least to my eyes it appears to comply with it, however i get a -104 error (Illegal symbol token) on the insert line.
The insert works fine provided i use values not from 'N'.
OK, it works if i have nothing in the if then statement.. but only if i have nothing!
Thanks
My guess would be that DB2 is confused by your statement terminators. You use a semicolon to terminate the CREATE TRIGGER statement, but at the same time you use the same terminator inside the CREATE TRIGGER statement, after the INSERT.
In whatever client you use to execute your code, redefine the statement terminator to something else and place that terminator at the end of CREATE TRIGGER, after END ID. For example, if you use the command line processor, save this to a file trig.sql:
CREATE OR REPLACE TRIGGER AUTO_INSERT_DEPO_NOMINEE
AFTER INSERT ON CA_ENTITLEMENT
REFERENCING NEW AS N
FOR EACH ROW
IF NOT EXISTS (SELECT D.DEPO_CD FROM DEPO D WHERE D.DEPO_CD = N.DEPO_CD)
THEN
INSERT INTO DEPO (DEPO_CD, DEPO_NME, BRANCH_CD, AUTO_GENERATED)
VALUES(N.DEPO_CD, NULL, N.BRANCH_CD, 'Y');
END IF#
then run it, specifying "#" as the statement terminator:
db2 -td# -f mytrig.sql
Or: What is not a T-SQL statement?
Except to resolve ambiguity, T-SQL syntax does not require a semicolon to terminate a statement. Despite this, Itzik Ben-Gan recommends using a semicolon to terminate a T-SQL statement because it makes code cleaner, more readable, easier to maintain, and more portable.
I don't know a precise definition of what a valid T-SQL statement is, so I might be confused here. But as far as I know, a BEGIN...END block is a T-SQL statement, so should be terminated by a semicolon. For example:
IF OBJECT_ID('tempdb.dbo.#TempTable') IS NOT NULL
BEGIN
DROP TABLE #TempTable;
END;
The code example in Microsoft's BEGIN...END documentation supports this conjecture:
USE AdventureWorks2008R2;
GO
BEGIN TRANSACTION;
GO
IF ##TRANCOUNT = 0
BEGIN
SELECT FirstName, MiddleName
FROM Person.Person WHERE LastName = 'Adams';
ROLLBACK TRANSACTION;
PRINT N'Rolling back the transaction two times would cause an error.';
END;
ROLLBACK TRANSACTION;
PRINT N'Rolled back the transaction.';
GO
/*
Rolled back the tranaction.
*/
Itzik Ben-Gan contradicts this in the code example of Excercise 1-1 of T-SQL Fundamentals:
SET NOCOUNT ON;
USE TSQLFundamentals2008;
IF OBJECT_ID('dbo.Nums', 'U') IS NOT NULL DROP TABLE dbo.Nums;
CREATE TABLE dbo.Nums(n INT NOT NULL PRIMARY KEY);
DECLARE #i AS INT = 1;
BEGIN TRAN
WHILE #i <= 100000
BEGIN
INSERT INTO dbo.Nums VALUES(#i);
SET #i = #i + 1;
END
COMMIT TRAN
SET NOCOUNT OFF;
Microsoft's Transact-SQL Syntax Conventions document states that the semicolon "will be required in a future version" of T-SQL.
Commenting on Microsoft's intention to require the semicolon in a future version of T-SQL, Itzik notes some exceptions that aren't supposed to be terminated:
So far it was a requirement to use a semicolon only in specific cases. Now it looks like the plan is to make it a required terminator for all* T-SQL statements in some future version of SQL Server.
(*) Naturally there are cases that aren’t supposed to be terminated with a semicolon; those include (but are not limited to):
BEGIN
BEGIN TRAN
IF
ELSE
WHILE
BEGIN TRY
END TRY
BEGIN CATCH
Itzik seems to be consistent with himself, but Microsoft itself does not follow his recommendations. Compare Microsoft's BEGIN TRANSACTION; and Itzik's BEGIN TRAN in the previous examples.
In the code I maintain, I have seen even the BEGIN keyword terminated by semicolon:
IF #HasWidget = 0x1
BEGIN;
SELECT WidgetID
FROM tbWidgets;
END;
I believe a T-SQL parser may consider the semicolon following the BEGIN keyword to terminate an empty statement rather than terminate the BEGIN keyword itself; I don't believe that BEGIN itself is a valid T-SQL statement.
This conjecture is supported by the fact that SQL Server 2008 successfully parses and executes the following query:
SELECT 0;;
It's so confusing because there is no widely available specification of the T-SQL language, like the Java Language Specification for Java, so nowhere is there a formal definition of a T-SQL statement.
Am I wrong? Does such a specification exist for T-SQL, and is it publicly available?
Otherwise, should just I believe what Itzik says?
T-SQL syntax does not require a semicolon to terminate a statement.
Actually, this is deprecated1. I can't remember for sure, but I think you can still get away with not using them in the upcoming SQL Server 2012, but some version after that will likely require a semi-colon for every statement. Using a semi-colon is also technically required by the ansi standard. The point is that now is the time to get in the habit of using one for every statement.
As a practical matter, I don't expect them to follow through with this directly. Rather, I expect SQL Server Management Studio and other development tools to first start issuing warnings instead of errors, perhaps for several versions. This will help developers find and fix all the old non-compliant code. But that doesn't lessen the message: semi-colons are coming, and soon.
For a simple heuristic on when not to use a semi-colon, think of the code as if it were a procedural language that used curly brackets for blocks, like C/C++. Statements that would be paired with an opening (not closing) curly bracket if written in the procedure language should not get a semi-colon.
1It's almost all the way at the bottom of the page
Summary, based on the OP's original, quoted list.
Yes semi-colon:
BEGIN TRAN;
No semi-colon:
BEGIN
IF
ELSE
WHILE
BEGIN TRY
END TRY
BEGIN CATCH
Also, use them after END and END CATCH.
Details:
BEGIN TRAN is a statement and should be terminated with a semi-colon.
Microsoft's documentation notes the optional semi-colon:
BEGIN { TRAN | TRANSACTION }
[ { transaction_name | #tran_name_variable }
[ WITH MARK [ 'description' ] ]
]
[ ; ]
Microsoft's example has semi-colons:
BEGIN TRAN T1;
UPDATE table1 ...;
BEGIN TRAN M2 WITH MARK;
UPDATE table2 ...;
SELECT * from table1;
COMMIT TRAN M2;
UPDATE table3 ...;
COMMIT TRAN T1;
Both of the above are from:
https://msdn.microsoft.com/en-us/library/ms188929(v=sql.90).aspx
They match the current documentation:
https://msdn.microsoft.com/en-us/library/ms188929(v=sql.120).aspx
As for BEGIN...END, the Microsoft documentation does not provide clear guidance.
The definition has no semi-colon:
BEGIN
{
sql_statement | statement_block
}
END
However, their example shows a semi-colon after END:
IF ##TRANCOUNT = 0
BEGIN
SELECT FirstName, MiddleName
FROM Person.Person WHERE LastName = 'Adams';
ROLLBACK TRANSACTION;
PRINT N'Rolling back the transaction two times would cause an error.';
END;
https://msdn.microsoft.com/en-us/library/ms190487.aspx
That trailing semi-colon is not consistent with Microsoft's own documentation for IF control of flow language construct:
IF Boolean_expression
{ sql_statement | statement_block }
[ ELSE
{ sql_statement | statement_block } ]
Neither that definition nor their code example shows any semi-colon:
DECLARE #compareprice money, #cost money
EXECUTE Production.uspGetList '%Bikes%', 700,
#compareprice OUT,
#cost OUTPUT
IF #cost <= #compareprice
BEGIN
PRINT 'These products can be purchased for less than
$'+RTRIM(CAST(#compareprice AS varchar(20)))+'.'
END
ELSE
PRINT 'The prices for all products in this category exceed
$'+ RTRIM(CAST(#compareprice AS varchar(20)))+'.'
https://msdn.microsoft.com/en-us/library/ms182717(v=sql.110).aspx
However, their ELSE documentation, while also not showing any semi-colon in the definition, does show one in the example, after the final END.
Definition:
IF Boolean_expression { sql_statement | statement_block }
[ ELSE { sql_statement | statement_block } ]
Example:
IF 1 = 1 PRINT 'Boolean_expression is true.'
ELSE PRINT 'Boolean_expression is false.' ;
https://msdn.microsoft.com/en-us/library/ms182587(v=sql.110).aspx
The ANSI standard doesn't resolve the ambiguity because these are non-standard extensions:
Control-of-flow statements are not covered by the ANSI SQL standard
because these are proprietary SQL extensions. The SQL Server Books
Online is sketchy on the subject and many of the examples (as of this
writing) are inconsistent and do not always include statement
terminators. Furthermore, control-of-flow statement blocks are
confusing due to the many variations, nesting, and optional BEGIN/END
specifications.
http://www.dbdelta.com/always-use-semicolon-statement-terminators/
However, the behavior of the server sheds some light. The following is not a syntax error in SQL Server 2005:
DECLARE #foo int;
IF #foo IS NULL
BEGIN
WITH Blah AS
(
SELECT
'a' AS a
)
SELECT
a
FROM Blah;
END
So the BEGIN itself does not require a semi-colon. However, the following does produce a syntax error in SQL Server 2005:
DECLARE #foo int;
IF #foo IS NULL
BEGIN
WITH Blah AS
(
SELECT
'a' AS a
)
SELECT
a
FROM Blah;
END
WITH Blah2 AS
(
SELECT
'a' AS a
)
SELECT
a
FROM Blah2;
The above results in this error:
Msg 319, Level 15, State 1, Line 13 Incorrect syntax near the keyword
'with'. If this statement is a common table expression or an
xmlnamespaces clause, the previous statement must be terminated with a
semicolon.
It also throws that error in SQL Server 2008 R2.
It gets even more confusing. Microsoft's documentation for TRY...CATCH shows an optional semi-colon after the END CATCH, and their examples are consistent with that.
BEGIN TRY
{ sql_statement | statement_block }
END TRY
BEGIN CATCH
[ { sql_statement | statement_block } ]
END CATCH
[ ; ]
However, if you have a CTE immediately after a BEGIN TRY, without a semi-colon, it will throw an error.
BEGIN TRY
WITH Blah AS
(
SELECT
'a' AS a
)
SELECT
a
FROM Blah;
END TRY
BEGIN CATCH
END CATCH
In SQL Server 2008 R2, the above batch throws this error:
Msg 319, Level 15, State 1, Line 2 Incorrect syntax near the keyword
'with'. If this statement is a common table expression, an
xmlnamespaces clause or a change tracking context clause, the previous
statement must be terminated with a semicolon.
The error implies that BEGIN TRY is a statement (which it isn't), and that a semi-colon "fixes" the issue (which it does). That's right, this works:
BEGIN TRY;
WITH Blah AS
(
SELECT
'a' AS a
)
SELECT
a
FROM Blah;
END TRY
BEGIN CATCH
END CATCH
However, Microsoft says that's not good practice:
Posted by Microsoft on 12/29/2009 at 12:11 PM I am resolving the
corresonding SQL11 bug as "by design". Here is the explanation:
The semicolon between END TRY and BEGIN CATCH should not be allowed,
because they are actually not different statements, but parts of the
same TRY-CATCH statement. We only allow semicolons when they separate
two statements in a sequence.
A word of explanation why then we allow semicolons after BEGIN TRY and
BEGIN CATCH. These keywords serve as opening "parentheses" that start
an embedded statement sequence. Semicolons after BEGIN TRY/BEGIN CATCH
get parsed as part of that embedded sequence, with the first statement
in the sequence being empty. While we allow this syntax, I would not
recommend it as a good coding practice because it creates a wrong
impression of BEGIN TRY/BEGIN CATCH being independent, standalone
statements.
The recommended way to handle that situation is with an extra BEGIN...END for clarity:
BEGIN TRY
BEGIN
WITH Blah AS
(
SELECT
'a' AS a
)
SELECT
a
FROM Blah;
END
END TRY
BEGIN CATCH
END CATCH
However, that END before the END TRY should probably have a semi-colon. After all, this will throw an error:
BEGIN TRY
BEGIN
WITH Blah AS
(
SELECT
'a' AS a
)
SELECT
a
FROM Blah;
END
WITH Blah2 AS
(
SELECT
'b' AS b
)
SELECT
b
FROM Blah2;
END TRY
BEGIN CATCH
END CATCH
Maybe always preceding a CTE WITH a semi-colon isn't so silly.
The only situation in which I frequently using a semicolon is when using Common Table Expressions via the WITH keyword - and only then because the WITH keyword must be preceded by a semicolon otherwise it returns an error. In those cases, I write
;WITH [exp]...
i.e. I precede the WITH with a semicolon, rather than terminate the previous statement.
Semicolon usage in SQL seems to be very rare; I occasionally see it after a stored procedure or function declaration by that is the exception rather than the rule. Of all the developers I've worked with I don't believe any have really used the semicolon in the way that you described.
Statements like
BEGIN;
SELECT WidgetID
FROM tbWidgets;
END;
are hard to understand - if BEGIN; is considered a statement independent of its corresponding END;, why is SELECT WidgetID not a valid statement independent of its corresponding FROM?