When creating a stored procedure, does the BEGIN/END block serve and purpose?
eg,
CREATE PROCEDURE SPNAME
AS
SELECT * FROM TABLE
vs.
CREATE PROCEDURE SPNAME
AS
BEGIN
SELECT * FROM TABLE
END
As indicated in the CREATE PROCEDURE documentation, the BEGIN/END is optional:
{ [ BEGIN ] sql_statement [;] [ ...n ]
[ END ] }
One or more Transact-SQL
statements comprising the body of the
procedure. You can use the optional
BEGIN and END keywords to enclose the
statements. For information, see the
Best Practices, General Remarks, and
Limitations and Restrictions sections
that follow.
As a matter of personal preference, I always include them.
To me, it is just an unnecessary extra indent level. However, if you make it a BEGIN TRY - END TRY with a BEGIN CATCH - END CATCH then it adds a real purpose.
The latter is just a good style of programming and following general standards.They don't differ in anything as far as I know.
I personally think it makes sense and improves readability to have a BEGIN and END around every logical chunk of code (even in stored procedures case).
There is no real pourpose in the case. But your code will be readable and clean if you use BEGIN/END blocks.
The BEGIN and END have no bearing for a stored procedure, however they are required for a Function.
Okay:
CREATE PROC dbo.sproc(#v varchar(10))
AS
RETURN -1
Not okay:
CREATE FUNCTION dbo.fun(#v varchar(10))
RETURNS INT
AS
RETURN 1
Related
I'm trying to create this trigger in my PostgresSql environment:
CREATE TRIGGER MYTRIGGER
BEFORE INSERT
ON MYTABLE
FOR EACH ROW
BEGIN
IF( LENGTH( :NEW.VAL ) > 10 )
THEN
RAISE_APPLICATION_ERROR( -20003,
'Cannot exceed 10 chars' );
END IF;
IF :NEW.FQN_ID IS NULL THEN
:NEW.FQN_ID :=
CASE :NEW.SUBTYPECODE
WHEN NULL THEN 'A:'
WHEN 0 THEN 'B:'
WHEN 1 THEN 'C:'
WHEN 2 THEN 'D:'
ELSE 'Z:' || :NEW.SUBTYPECODE || '::'
--END || :NEW.OBJECTID;
END || STRUCTURE_FQNID_SEQ.NEXTVAL;
END IF;
END;
But I get this error:
ERROR: syntax error at or near "BEGIN"
LINE 5: BEGIN
^
SQL state: 42601
Character: 79
I think I'm missing something but I can't get it.
Any suggestion would be greatly appreciated.
Thank you.
Here are my notes about triggers in several DBMSs: https://github.com/iwis/SQL-notes. I marked the differences between the DBMSs in orange. I think that the notes are quite complete, so you don't have to read about triggers in Postgres documentation.
I see the following changes that need to done in your example:
Change Oracle :NEW to Postgres NEW.
Instead of a BEGIN ... END block, write EXECUTE FUNCTION my_trigger_function();, where my_trigger_function is a function that needs to be created like in the example given by a_horse_with_no_name.
This function should return NEW in your case - the reason is described here.
If a more complicated code is fired by a trigger, then you also need to understand the differences between PL/SQL and PL/pgSQL languages. These languages are quite similar, though there are some differences. Your code is simple so the differences are small. It's probably enough to:
Write Postgres RETURNS in the function definition instead of Oracle RETURN.
Write $$ before BEGIN, and $$ LANGUAGE plpgsql; after END.
Write Postgres RAISE 'Cannot exceed 10 chars'; instead of Oracle RAISE_APPLICATION_ERROR(-20003, 'Cannot exceed 10 chars');.
I don't know if sequences work in the same way in PostgreSQL - I haven't read about them yet.
Let me know if my notes are understandable - I'm not sure about it because they are super compact so you need to decipher the markings used by me.
Common sense dictates that SQL query strings should never be assembled by hand. Thus, all database interfaces offer parameter substitution, and all users use it, without exceptions.*
I'm using PostgreSQL v10.5, nodejs v8.12.0, node-postgres 7.6.1.
Parameter substitution works as expected for SELECT statements:
> await db.query("select from users where id = 'mic'");
(success, 1 row returned)
> await db.query("select from users where id = $1", ["mic"]);
(success, 1 row returned)
But it doesn't work for LISTEN statements:
> await db.query("listen topicname");
(success)
> await db.query("listen $1", ["topicname"]);
(error: syntax error at or near "$1")
The name of the topic I want to listen to is dynamic. It is coming from semi-trustworthy sources, which should not be user-controllable. But why go against all established best practice and take any chances?
Unfortunately, from my tests I fear that PostgreSQL simply can't do parameter substitution for LISTEN queries.
Is there any solution or workaround for this?
*) This statement may only be true in some utopic future society.
I don't have enough reputation to comment on the answer, but the proposed solution doesn't work for me.
Using %L results in a quoted string, which causes the following error:
ERROR: syntax error at or near "'topic'"
The %I format should be used instead (SQL identifier, this is documented for table and column names, but it also works for the channel name,). You can also use the quote_ident function. See the documentation on creating dynamic queries here.
The following PL/pgSQL function works for us:
CREATE OR REPLACE FUNCTION listenForChannel(
channel_ TEXT
) RETURNS VOID AS $$
BEGIN
EXECUTE format('LISTEN %I', channel_);
END
$$ LANGUAGE PLPGSQL;
You are right that this cannot be done in PostgreSQL.
As a workaround, write a PL/pgSQL function that uses dynamic SQL like this:
EXECUTE format('LISTEN %L', topicname);
The format function escapes strings properly; in this case, the %L format that produces a properly quoted string Literal is the appropriate one.
I just noticed that I could alter my stored procedure code with a misspelled user defined function in it.
I noticed that at 1st time I execute the SP.
Is there any way to get a compile error when an SP include an invalid user-defined function name in it?
At compile time? No.
You can, however, use some of SQL's dependency objects (if using MS SQL) to find problems just after deployment, or as part of your beta testing. Aaron Bertran has a pretty nice article rounding up the options, depending upon the version of SQL Server.
Here is an example using SQL Server 2008 sys object called sql_expression_dependencies
CREATE FUNCTION dbo.scalarTest
(
#input1 INT,
#input2 INT
)
RETURNS INT
AS
BEGIN
-- Declare the return variable here
DECLARE #ResultVar int
-- Add the T-SQL statements to compute the return value here
SELECT #ResultVar = #input1 * #input2
-- Return the result of the function
RETURN #ResultVar
END
GO
--Fn Works!
SELECT dbo.ScalarTest(2,2)
GO
CREATE PROCEDURE dbo.procTest
AS
BEGIN
SELECT TOP 1 dbo.scalarTest(3, 3) as procResult
FROM sys.objects
END
GO
--Sproc Works!
EXEC dbo.procTest
GO
--Remove a dependency needed by our sproc
DROP FUNCTION dbo.scalarTest
GO
--Does anything have a broken dependency? YES
SELECT OBJECT_NAME(referencing_id) AS referencing_entity_name,
referenced_entity_name, *
FROM sys.sql_expression_dependencies
WHERE referenced_id IS NULL --dependency is missing
GO
--Does it work? No
EXEC dbo.procTest
GO
I am using Sybase ASE 12.5 at the moment. I have a code below:
create procedure test_launcher_fail_wrapper
as
begin
select convert(numeric(2),1234345)
if ##error != 0
begin
select "SP failed to execute"
return 1
end
end
Here, I am trying to convert a very large value/amount (1234345) to Numeric size 2. Which is not possible and it generates error.
Questions:
Is having ##error useful here? I ran this SP and it never went into
error handling
How to error handle these kind of scenarios?
I treat error handling in procs similarly to error handling in applications -- if there's an opportunity for you to contribute some actual value by handling the error, then by all means, do so, but if you can't really do anything to help, then you're better off just letting it go.
As an example of adding value, I've got one or two procs that add contextual information in the error message, like a list of ID values that conflict with an update operation. In this particular case, I know that the upstream consumer of the proc will log this error, and the text will be available to an operator who will find this information valuable when debugging the problem. I also know that while this condition is a real error, it's been known to happen from time-to-time, and the effort to format the error is worthwhile.
Does this catch your error?
create procedure test_launcher_fail_wrapper
as
begin
declare #database_err int
set #database_err = 0
select convert(numeric(2),1234345)
set #database_err = ##error
if #database_err <> 0
begin
PRINT 'SP failed to execute'
return 1
end
end
##error is the way to go but beware since:
Every Transact-SQL statement, including print statements and if tests, resets ##error, so the status check must immediately follow the batch for which success is in question.
As for a suggestion on how to handle error management in similar scenarios, have you considered using raiserror ?
An example:
create procedure proc1 as
begin
select convert(numeric(2),1234345)
if ##error <> 0
begin
raiserror 20001 "Error during convert in proc1"
return 1
end
end
Is it possible to have database wide constants?
What I want is to define a constant like:
UPDATE_CONSTANT = 1
INSERT_CONSTANT = 2
DELETE_CONSTANT = 3
and then use it in for example a trigger like:
CREATE TRIGGER AD_PRJ_PROJECTS FOR PRJ_PROJECT
ACTIVE AFTER DELETE
POSITION 1
AS
BEGIN
EXECUTE PROCEDURE SP_ADD_HISTORY 'PRJ_PROJECT', DELETE_CONSTANT;
END;
You could use a generator:
SET GENERATOR DELETE_CONSTANT TO 3;
...
EXECUTE PROCEDURE SP_ADD_HISTORY 'PRJ_PROJECT', GEN_ID(DELETE_CONSTANT, 0);
Update: yes, using a generator for this purpose is dangerous, as they can be changed.
However, in FireBird 3.0 Alpha 1 this risk can be eliminated using access rights: Grants access on generators.
I don't think there is an easy way for declaring constants.
I could be done by creating you own DLL for user defined function, and lmake a function for each constant.
I Think the Idea using generators as "global" constants is briliant.
But you can make a "local constant" to make your code a bit more readable:
CREATE TRIGGER AD_PRJ_PROJECTS FOR PRJ_PROJECT
ACTIVE AFTER DELETE
POSITION 1
AS
DECLARE VARIABLE DELETE_CONSTANT INTEGER;
BEGIN
DELETE_CONSTANT = 1;
EXECUTE PROCEDURE SP_ADD_HISTORY 'PRJ_PROJECT', DELETE_CONSTANT;
END;
Use a single row table with triggers that prevent insertion and deletion from it. Having to read from it certainly does not makes code clearer but it helps to implement such "constants". Also remove write permissions from everybody but sysdba
You can implement some simple preprocesor of yours scripts that converts constants to values..
triggers.presql
#DELETE_CONSTANT = 1
CREATE TRIGGER AD_PRJ_PROJECTS FOR PRJ_PROJECT
ACTIVE AFTER DELETE
POSITION 1
BEGIN
EXECUTE PROCEDURE SP_ADD_HISTORY 'PRJ_PROJECT', DELETE_CONSTANT;
END;
triggers.sql
CREATE TRIGGER AD_PRJ_PROJECTS FOR PRJ_PROJECT
ACTIVE AFTER DELETE
POSITION 1
BEGIN
EXECUTE PROCEDURE SP_ADD_HISTORY 'PRJ_PROJECT', 1;
END;