I am new to PostgreSQL and am using the query tool in PGAdmin. I'm trying to run pgsql queries that use variables, but I can't seem to get the syntax right.
Here's a sample query that gives a syntax error:
DECLARE
num INTEGER;
BEGIN
num := 3;
PRINT num;
END;
Update:
Ok, let me try and explain. I come from a SQL server background. In the management studio, I can open a query window and play with (T)-SQL queries.
For example, I can write something like this:
DECLARE #num INT
SET #num = 3
SELECT #num
I know this is a dumb example, but I'm just trying to declare a variable and do something with it. I'm trying to familiarise myself with PL/PGSQL.
Update, again:
It's me again. I'm trying the script below and get a "[ERROR ] 7.0-2: syntax error, unexpected character". Is this meant to work in PGAdmin?
DECLARE
num INTEGER;
BEGIN
num := 3;
RAISE NOTICE '%', num;
END;
You can use the do statement. For example:
do $$
declare
num integer := 10;
begin
RAISE INFO 'VARIABLE: %', num;
end;
$$language plpgsql;
When you use pgadmin you have to use the button EXECUTE QUERY instead of
Execute pdScript, as it is explained here:
http://postgresql.1045698.n5.nabble.com/PgAmin3-Anonymous-code-block-can-t-be-executed-by-pressing-quot-Execute-PG-script-quot-button-td5771073.html
The documentation for do statements is here:
http://www.postgresql.org/docs/9.3/static/sql-do.html
Just to rephrase and "concretize" what others say:
There are no inline procedures in PostgreSQL. There is also no PRINT statement. You have to:
CREATE OR REPLACE FUNCTION test() RETURNS void AS $$
DECLARE
num INTEGER;
BEGIN
num := 3;
RAISE NOTICE '%', num;
END;
$$ LANGUAGE plpgsql;
SELECT test();
If you're trying to print out num (say, for debugging), you could try:
RAISE NOTICE '%', num;
http://www.postgresql.org/docs/8.4/static/plpgsql-errors-and-messages.html
PRINT doesn't mean anything in PL/pgSQL.
I have no idea what you are trying to achieve. PostgreSQL doesn't support this kind of syntax. Similar keywords (except PRINT?!) are in PL/pgSQL which is procedural language for building FUNCTIONS, not for writing stand-alone SQL queries.
Postgres doesn't support anything like that by itself (yet). psql (the official command line client) has some rudimentary scripting.
The best option for you is pgAdmin which already has scripting built-in.
Related
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 have a Postgres script that I have that I intend to run against multiple databases. The sample SQL has functions and tables like
CREATE FUNCTION point() RETURNS trigger
LANGUAGE plpgsql
AS $$
BEGIN
NEW.the_geom:=ST_SetSRID(geom, :CRS) ;
RETURN NEW;
END
$$;
CREATE TABLE admin (
gid integer NOT NULL,
geom geometry(Polygon,:CRS)
);
I have put a variable inside so that I can substitute it on runtime as
psql -d db -p 5432 -U username -h localhost -f test.sql --variable=CRS=3857
Why does the variable only get properly substituted in table definitions and not function definition
https://www.postgresql.org/docs/current/static/app-psql.html#APP-PSQL-INTERPOLATION
Therefore, a construction such as ':foo' doesn't work to produce a
quoted literal from a variable's value (and it would be unsafe if it
did work, since it wouldn't correctly handle quotes embedded in the
value).
a function definition is put between quotes - in your case $$ instead of ', so it fails. You can change ST_SetSRID(geom, :CRS) to ST_SetSRID(geom, $$:CRS) to see it start being handled again (of course ruining the function body)
As a workaround you can try using bash variable instead:
vao#vao-VirtualBox:~$ export CRS=33
vao#vao-VirtualBox:~$ psql t << EOF
> CREATE OR REPLACE FUNCTION point() RETURNS trigger
> LANGUAGE plpgsql
> AS \$\$
> BEGIN
> NEW.the_geom:=ST_SetSRID(geom, $CRS) ;
> RETURN NEW;
> END
> \$\$;
> \sf point()
> EOF
CREATE FUNCTION
CREATE OR REPLACE FUNCTION public.point()
RETURNS trigger
LANGUAGE plpgsql
AS $function$
BEGIN
NEW.the_geom:=ST_SetSRID(geom, 33) ;
RETURN NEW;
END
$function$
Of course it can be scripted to a file that you can call as bash with argument
Shell substitution, as Vao Tsun suggests, might work fine for small psql scripts, but it's still not a general solution. For instance, shells are not aware of psql and pgSQL syntaxes and may substitute sub-strings that are not meant to be substituted in the psql script:
-- If CA and AU are undefined environment variable (likely),
-- the following SQL, after shell substitution, will result in:
-- ... VALUES ('Australian Dollar', ''), (Canadian Dollar, '');
INSERT (name, symbol) INTO currencies VALUES
('Australian Dollar', '$AU'),
('Canadian Dollar', '$CA');
This will become unmanageable with large scripts without additional measures. A better approach is to use string concatenation. Something like this would be ideal:
-- This won't work; syntax error
CREATE FUNCTION point() RETURNS trigger
LANGUAGE plpgsql
AS $$
BEGIN
NEW.the_geom := ST_SetSRID(geom, $$ || :'CRS' || $$);
RETURN NEW;
END
$$;
Unfortunately, pgSQL syntax expects literal strings as function bodies, not arbitrary string expressions. Fortunately, however, PostgreSQL implements as part of its SQL syntax implicit concatenation between single-quoted strings separated by only whitespaces and at least one line break:
-- This gets parsed as "SELECT 'mystring';"
SELECT 'my'
'string';
The catch though is that it only works with single-quoted strings, not dollar-quoted strings. The following will work fine, but it's an eye-sore:
-- This will work, but it's ugly
CREATE FUNCTION point() RETURNS trigger
LANGUAGE plpgsql
AS
-- Mind the trailing space below
'BEGIN '
'NEW.the_geom := ST_SetSRID(geom, $$'
:'CRS'
'$$);'
'RETURN NEW;'
'END';
This is perhaps a more eye-pleasing variant:
-- This will work
-- (assign appropriate ownership and permissions if CRS contains sentitive data)
CREATE FUNCTION _get_crs() RETURNS text LANGUAGE sql AS 'SELECT $$'
:'crs'
'$$';
CREATE FUNCTION point() RETURNS trigger
LANGUAGE plpgsql
AS $$
BEGIN
NEW.the_geom := ST_SetSRID(geom, _get_crs());
RETURN NEW;
END
$$;
And here's another variant:
-- This will also work
-- (may expose sensitive data in the catalog)
SET "app.crs" = :'crs';
CREATE FUNCTION point() RETURNS trigger
LANGUAGE plpgsql
AS $$
BEGIN
NEW.the_geom := ST_SetSRID(geom, current_setting('app.crs'));
RETURN NEW;
END
$$;
The function body is a sting literal. psql has hardly any string modification functionality. However, PostgreSQL has plenty of it. With psql variables and \gset (since PostgreSQL 9.3) you can utilize this to first build your command and then execute it:
--for demo purpose set CRS directly. The OP did pass it from outside to psql
\set CRS 1234
--here we wrap the whole CREATE FUNCTION call in a literal separated by $_$
--this improves the readabilty and covers the inner $$. The result will be
--stored in psql variable func. This is workaround for a multi-line \set
SELECT $_$
CREATE FUNCTION point() RETURNS trigger
LANGUAGE plpgsql
AS $$
BEGIN
NEW.the_geom:=ST_SetSRID(geom, :CRS) ;
RETURN NEW;
END
$$;
$_$ AS func \gset
--replace the substring ':CRS' with content of variable CRS
--and store the result in func again
SELECT replace(:'func', ':CRS', :'CRS') AS func \gset
--we can now have a look to the resulting DDL
\echo :func
--and we can execute it:
:func
--clean up psql variables
\unset func
\unset CRS
with the help of \gexec (since PostgreSQL 9.6) we can also combine the last two steps:
--replace the substring ':CRS' with content of variable CRS
--and execute the result
SELECT replace(:'func', ':CRS', :'CRS') \gexec
or even do all in one command:
SELECT replace($_$
CREATE FUNCTION point() RETURNS trigger
LANGUAGE plpgsql
AS $$
BEGIN
NEW.the_geom:=ST_SetSRID(geom, :CRS) ;
RETURN NEW;
END
$$;
$_$, ':CRS', :'CRS') \gexec
I have a problem with an array parameter going into a plpgsql function. My code works in PostgreSQL 8.3, but fails when called on a 9.2.1 server.
I have written a dummy function that shows the problem. This is based on some of the first plpgsql code I have written. I know it is ugly, so if it is not possible to escape my quotes in a way that works for both server versions, I am open to suggestions on rewriting this code so that it works on both server versions. Actually I am open to suggestions no matter what. I am not too good at plpgsql
So here's the dummy code that demonstrates the problem:
CREATE OR REPLACE FUNCTION get_test(collection text[])
RETURNS text AS
$BODY$
DECLARE
counter int8; directive text; condition text; querytype text;
BEGIN
counter = array_lower(collection, 1);
WHILE (counter <= array_upper(collection, 1)) LOOP
SELECT INTO directive "?column?"[counter] FROM (SELECT collection) AS foo ;
counter = counter + 1;
SELECT INTO condition "?column?"[counter] FROM (SELECT collection) AS foo ;
counter = counter + 1;
SELECT into querytype "?column?"[counter] FROM (SELECT collection) AS foo ;
counter = counter + 1;
END LOOP;
RETURN 'dummy';
END;
$BODY$
LANGUAGE plpgsql VOLATILE
COST 100;
ALTER FUNCTION get_test(text[]) OWNER TO postgres;
The collection parameter is built in sets of three (a simple string, a SQL condition, and another string). Here is an example call that works in 8.3 and fails in 9.2:
select * from get_test('{"dynamic","(tr.PROJECT_NAME = \'SampleProject\')","1"}')
This gives back 'dummy' as expected on 8.3, but fails on 9.2 with:
ERROR: syntax error at or near "SampleProject"
The caret points to the S of SampleProject, right after the single-quote, so I know I am
not escaping the single quotes in the embedded SQL correctly.
I have tried this without the backslashes in front of the single quotes, with two backslashes, and finally with two single quotes, all to no avail. The original code is called by a Java client, but I have been testing this under pgadmin3 (version 1.16), connecting to two servers of the versions in question, trying different things.
Any ideas as to how I can make this call work?
Most likely reason is a different setting for standard_conforming_strings.
Try this call:
The SQL-standard way (and recommended in PostgreSQL) to escape single quotes inside a single-quoted string literal is to double them:
SELECT *
FROM get_test('{dynamic,(tr.PROJECT_NAME = ''SampleProject''),1}'::text[])
OR:
SELECT *
FROM get_test('{dynamic,"(tr.PROJECT_NAME = ''SampleProject'')",1}'::text[])
Or you can resort to dollar-quoting to avoid multiple layers of escaping quotes
SELECT *
FROM get_test($${dynamic,"(tr.PROJECT_NAME = 'SampleProject')",1}$$::text[])
Or even an ARRAY constructor:
SELECT *
FROM get_test(ARRAY['dynamic','(tr.PROJECT_NAME = ''SampleProject'')','1'])
I may be contorting postgres here, but fundamentally, what I would like to do is take a string variable and pass it to an sql command (in this case COPY) using only psql.
So this is what I came up with. The commands are separated into 2 files because I want to be able to use the mydb_functions in other situations:
file one: mydb_functions--1.0.sql (in share/extension and with mydb_functions.control also setup as described in the manual. Given a filename, returns a full filepath. this is done solely to make the COPY statements in add_data.sql below, neater.
CREATE OR REPLACE FUNCTION fpn(filename text) RETURNS TEXT as '
DECLARE
mypath text := ''/path/to/my/directory/'';
BEGIN
RETURN mypath || filename;
END
' LANGUAGE plpgsql;
file two: add_data.sql . This exists solely to copy data into existing postgres tables using psql at the command line. Note: running psql with superuser privileges is required because of the CREATE EXTENSION command.
CREATE EXTENSION IF NOT EXISTS mydb_functions;
-- haven't figured out how to create a function without arguments yet.
CREATE OR REPLACE FUNCTION test (dummyvar text) RETURNS text as '
DECLARE
filepath RECORD;
BEGIN
SELECT * INTO filepath from fpn(''mydatafile.data'');
COPY tablename (columnname) FROM filepath;
END
' LANGUAGE plpgsql;
The part I am stuck on is how to extract a text from the filepath record to use in the COPY command. Any tips on an easier way to achieve this are also welcome. I think creating a table to store the variable is far easier than this. But I would like to finish the last step.
If your issue is running COPY with a dynamic target path, use EXECUTE to run a formatted SQL query.
CREATE OR REPLACE FUNCTION test () RETURNS text as $$
DECLARE
filepath RECORD;
BEGIN
SELECT * INTO filepath from fpn('mydatafile.data');
EXECUTE format('COPY tablename (columnname) FROM %L', filepath);
END
$$ LANGUAGE plpgsql;
See, this fails:
DO
$$
DECLARE
somevar text;
BEGIN
somevar := '/tmp/somepath.csv';
COPY tablename(columnname) FROM somevar;
END;
$$;
but this works:
DO
$$
DECLARE
somevar text;
BEGIN
somevar := '/tmp/somepath.csv';
EXECUTE format('COPY tablename(columnname) FROM %L', somevar);
END;
$$;
See:
EXECUTE
format()
format()'s %L specifier auto-quotes literals. %I does the same for identifiers.
If as I originally thought, you're talking about getting data into psql from outside, you may find psql variables and variable interpolation useful:
$ psql -v filepath=/path/to/my/directory/mydatafile.data regress
regress=> SELECT :'filepath';
?column?
---------------------------------------
/path/to/my/directory/mydatafile.data
(1 row)
Note that the colon is unquoted, then the variable name is quoted. Odd syntax, I know. This only works in psql; it won't work in (say) PgAdmin-III.
Alternately, you can use a here-document (unix-like shell specific, won't work in Windows' cmd.exe) to do quoted text interpolation:
$ FILEPATH=/path/to/my/directory/mydatafile.data
$ psql regress <<__END__
SELECT '$FILEPATH';
__END__
?column?
---------------------------------------
/path/to/my/directory/mydatafile.data
(1 row)
Both of these show how to insert a variable from the shell level into psql. From there, it's a matter of using it in your function. Like this, say, with -v filename=myfilename.csv:
CREATE OR REPLACE FUNCTION test() RETURNS text as $$
DECLARE
filepath RECORD;
BEGIN
SELECT * INTO filepath from fpn(:'filename');
COPY tablename (columnname) FROM filepath;
END
$$ LANGUAGE plpgsql;
or just this with -v filepath=/full/path/to/myfilename.csv:
$ psql -v filepath=/path/to/my/directory/mydatafile.data regress
regress=> COPY tablename (columnname) FROM :'filepath';
I'm trying to get a PSQL script running using variables in an example like the one below without declaring functions and having to call them.
DECLARE
result TEXT;
BEGIN
SELECT INTO result name
FROM test;
RAISE NOTICE result;
END;
Where table test only has 1 row and column. Is this possible without having to wrap this script inside a function. This will allow me to call the script via say command line easier.
Thanks guys.
You can use DO to create and execute an anonymous function:
DO executes an anonymous code block, or in other words a transient anonymous function in a procedural language.
Something like this:
do $$
declare result text;
begin
select name into result from test;
raise notice '%', result;
end;
$$;
I also fixed your raise notice.
If you just want to dump the single value from the table to the standard output in a minimal format (i.e. easy to parse), then perhaps --tuples-only will help:
-t
--tuples-only
Turn off printing of column names and result row count footers, etc. This is equivalent to the \t command.
So you could say things like this from the shell:
result=$(echo 'select name from test;' | psql -t ...)