When performing a loop on a table in which a value has ", I get those quotes doubled such as:
initial input: 'test AND "test"'
output in the loop: 'test AND ""test""'
How to reproduce:
CREATE TABLE roles(
id int,
criteria VARCHAR (255)
);
INSERT INTO roles (id, criteria) VALUES (1, 'test AND "test"');
CREATE OR REPLACE FUNCTION test_quote()
RETURNS VARCHAR
LANGUAGE plpgsql
AS $$
DECLARE
sample varchar;
rec record;
BEGIN
FOR rec IN
SELECT * FROM roles
LOOP
sample:= rec;
END LOOP;
RETURN sample;
END
$$;
SELECT * FROM test_quote();
Expected result: (1,"test AND "test"")
Actual result: (1,"test AND ""test""")
Does anyone have an idea how to get the expected behaviour here?
Found it, indeed, the issue is from the conversion from record to varchar.
I can directly pass the column from the rec like:
sample:= rec.criteria;
(I didn't know that we could do that)
So, that gives:
CREATE TABLE roles(
id int,
criteria VARCHAR (255)
);
INSERT INTO roles (id, criteria) VALUES (1, 'test AND "test"');
CREATE OR REPLACE FUNCTION test_quote()
RETURNS VARCHAR
LANGUAGE plpgsql
AS $$
DECLARE
sample varchar;
rec record;
BEGIN
FOR rec IN
SELECT * FROM roles
LOOP
sample := rec.criteria;
END LOOP;
RETURN sample;
END
$$;
SELECT * FROM test_quote();
Thx guys!
Using PostgreSQL 13.2, wherein a stored procedure (the Requestor) is given a name of a list of stored procedures to run (the job group). All sp's executed this way are coded to write a log record as their last task. I have chosen to pull that 'append log' code from all of the sp's, and instead send back the log record (always a single record) using an INOUT rowtype param, but have run into trouble. In my example below, the requestor sp will load the records returned from the sp's it calls into a temp table shaped like the permanent log table.
That permanent table looks like this:
create table public.job_log (
log_id integer,
event_id integer,
job_id integer,
rows_affected integer);
Any one of the jobs that is executed by the requestor sp might look like this one:
CREATE OR REPLACE procedure public.get_log_rcd(
inout p_log_rcd public.job_log)
LANGUAGE 'plpgsql'
as
$BODY$
declare
v_log_id integer = 40;
v_event_id integer = 698;
v_job_id integer = 45;
v_rows_affected integer = 60;
begin
select
v_log_id
, v_event_id
, v_job_id
, v_rows_affected
into
p_log_rcd.log_id,
p_log_rcd.event_id,
p_log_rcd.job_id,
p_log_rcd.rows_affected;
end;
$BODY$
This sample sp doesn't do anything--it's purpose here is only to simulate initialize of the log parameters to return to caller.
Again, the requestor sp that's going to run jobs like the one above creates a temp table with the same structure as the permanent log:
drop table if exists tmp_log_cache;
create temp table tmp_log_cache as table public.job_log with no data;
If the requestor sp didn't have to do dynamic SQL, it would look something like this block here:
do
$$
declare
big_local public.job_log;
begin
call public.get_log_rcd( big_local );
insert into tmp_log_cache (
log_id
, event_id
, job_id
, rows_affected )
values (
big_local.log_id
, big_local.event_id
, big_local.job_id
, big_local.rows_affected);
end;
$$;
Doing a
select * from tmp_log_cache;
Returns a row containing the 4 column values expected, all is well. But, dynamic execution is required. And, as I'm sure most folks here know, the following dog don't hunt:
do
$$
declare
big_local public.job_log;
v_query_text varchar;
v_job_name varchar = 'public.get_log_rcd';
begin
select 'call ' || v_job_name || '( $1 );'
into v_query_text;
execute v_query_text using big_local::public.job_log;
insert into tmp_log_cache (
log_id
, event_id
, job_id
, rows_affected )
values (
big_local.log_id
, big_local.event_id
, big_local.job_id
, big_local.rows_affected);
end;
$$;
The above dynamic statement executes without error, but the insert statement only has NULL values to work with--a row is inserted, all nulls. Any suggestions warmly welcomed. The sp's that comprise the various job groups could probably have been implemented as functions, although in all cases their primary tasks are to massage, normalize, cleanse telemetry data, not to spit anything out, per se.
Hmm, the documentation states that "parameter symbols (...) only work in SELECT, INSERT, UPDATE, and DELETE commands.", so this probably isn't possible using parameters.
But as a workaround you can build a dynamic DO and include a variable to get the values and the INSERT in there.
DO
$o$
DECLARE
v_query_text varchar;
v_job_name varchar := format('%I.%I',
'public',
'get_log_rcd');
BEGIN
v_query_text := concat('DO ',
'$i$ ',
'DECLARE ',
' big_local public.job_log; ',
'BEGIN ',
' CALL ', v_job_name, '(big_local); ',
' INSERT INTO tmp_log_cache ',
' (log_id, ',
' event_id, ',
' job_id, ',
' rows_affected) ',
' VALUES (big_local.log_id, ',
' big_local.event_id, ',
' big_local.job_id, '
' big_local.rows_affected); ',
'END; ',
'$i$; ');
EXECUTE v_query_text;
END;
$o$;
db<>fiddle
Thanks--I would not have considered the ability to execute a 'do' using execute. It just would not have occurred to me. Well, here's my solution: flip to functions.
With the understanding that my 'Requestor' is only given sp's to run because that's what we had to do with SQL Server and it was reflex, I did the 1-line change needed to flip my example sp above to a function:
CREATE OR REPLACE function public.get_log_rcdf(
inout p_log_rcd public.job_log)
returns public.job_log
LANGUAGE 'plpgsql'
as
$BODY$
declare
v_log_id integer = 40;
v_event_id integer = 698;
v_job_id integer = 45;
v_rows_affected integer = 60;
begin
select
v_log_id
, v_event_id
, v_job_id
, v_rows_affected
into
p_log_rcd.log_id,
p_log_rcd.event_id,
p_log_rcd.job_id,
p_log_rcd.rows_affected;
end;
$BODY$
In fact, the change to a function required the addition of a RETURNS line. Done. Then, the dynamic call was tweaked to a SELECT and the execute modified with an INTO:
do
$$
declare
big_local public.job_log;
v_query_text varchar;
v_job_name varchar = 'public.get_log_rcdf';
begin
select 'select * from ' || v_job_name || '( $1 );'
into v_query_text;
raise info 'SQL text is: %', v_query_text;
execute v_query_text into big_local using big_local;
insert into tmp_log_cache (
log_id
, event_id
, job_id
, rows_affected )
values (
big_local.log_id
, big_local.event_id
, big_local.job_id
, big_local.rows_affected);
end;
$$;
and the process now works exactly as desired. I tidy up my handling of the dynamic function name as illustrated in the first answer, and I think we're done here.
I am trying to return some data I have from Common Table Expression to my backend but unable to because Postgres doesn't see the table.
CREATE OR REPLACE FUNCTION request(
question_id_func INTEGER,
requester_account_id_func INTEGER,
counter_func NUMERIC
) RETURNS INTEGER AS $$
with notif AS (
INSET INTO notification(...) VALUES (...) RETURNING *
)
UPDATE question....
RETURN (SELECT notif_id FROM notif);
END $$ LANGUAGE PLPGSQL
Does anyone has a better idea how you can extract the data from CTE and return it?
Much appreciated.
You will need to put your UPDATE statement into a CTE, and then assign the output to a function variable using a final SELECT statement.
For example:
CREATE OR REPLACE FUNCTION request(
question_id_func INTEGER,
requester_account_id_func INTEGER,
counter_func NUMERIC
) RETURNS INTEGER AS $body$
DECLARE
result integer;
BEGIN
WITH notif AS (
INSERT INTO notification(...) VALUES (...) RETURNING *
),
question_update AS (
UPDATE question....
)
SELECT notif.notif_id INTO result FROM notif;
RETURN result;
END $body$ LANGUAGE PLPGSQL
How do I declare a variable for used in a PostgreSQL 9.3 query?
CREATE or replace FUNCTION public.test()
returns int4
AS
$BODY$
DECLARE
cod_process bigint :=30001;
cod_instance bigint ;
utc_log timestamp without time zone := localtimestamp;
cod_log_type varchar(100) :='information ';
txt_log_text varchar(100):= 'start process';
txt_log varchar(100):= txt_log_text||'_'||cod_process;
set cod_instance= select max(cod_instance) as cod_instance from public.instance where public.instance.cod_process=cod_process;
BEGIN
INSERT INTO public.log (cod_process, cod_instance, utc_log,cod_log_type,txt_log)
VALUES (cod_process, cod_instance, utc_log,cod_log_type,txt_log );
RETURN 11;
END;
$BODY$ LANGUAGE 'plpgsql';
ERROR: type "cod_instance" does not exist
SQL state: 42704
Character: 383
Your demo function would work like this:
CREATE or replace FUNCTION public.test()
RETURNS int4 AS
$func$
DECLARE
_cod_process bigint := 30001;
_cod_instance bigint := (SELECT max(cod_instance)
FROM public.instance
WHERE cod_process = _cod_process);
_utc_log timestamp := localtimestamp;
_cod_log_type varchar(100) := 'information';
_txt_log_text varchar(100) := 'start process';
_txt_log varchar(100) := txt_log_text || '_' || cod_process;
BEGIN
INSERT INTO public.log
( cod_process, cod_instance, utc_log, cod_log_type, txt_log)
VALUES (_cod_process, _cod_instance, _utc_log, _cod_log_type, _txt_log);
RETURN 11;
END
$func$ LANGUAGE plpgsql;
Major points
You cannot use SET to assign a variable. That's taken to be the SQL command SET for setting run-time parameters.
But you can assign a variable at declaration time, even use a subquery for that.
UseLANGUAGE plpgsql, not LANGUAGE 'plpgsql'. It's an identifier.
#a_horse_with_no_name already wrote about naming conflicts.
Using a clean format goes a long way when debugging code ...
But you can probably simplify to:
CREATE OR REPLACE FUNCTION public.test(_cod_process bigint = 30001)
RETURNS integer AS
$func$
INSERT INTO public.log
(cod_process, cod_instance , utc_log, cod_log_type , txt_log)
SELECT $1, max(cod_instance), now() , 'information', 'start process_' || $1
FROM public.instance
WHERE cod_process = $1
GROUP BY cod_process
RETURNING 11
$func$ LANGUAGE sql;
Call:
SELECT public.test(); -- for default 30001
SELECT public.test(1234);
And depending on the actual data type of utc_log you probably want now() AT TIME ZONE 'UTC':
Ignoring timezones altogether in Rails and PostgreSQL
You need to run the select using the into clause inside the actual code block, not in the declare block:
begin
select max(cod_instance)
into cod_instance
from public.instance
where public.instance.cod_process=cod_process;
....
end;
It's usually not such a good idea to give variables (or parameters) the same name as columns in the table. There are certain cases where this can confuse the parser. To avoid any potential problems, try to use different names for your variables, e.g. by prefixing them (e.g. l_cod_process instead of cod_process or l_cod_instance instead of cod_instance)
More details on variable assignment can be found in the manual: http://www.postgresql.org/docs/current/static/plpgsql-statements.html
Something like this:
CREATE OR REPLACE FUNCTION get(param_id integer)
RETURNS integer AS
$BODY$
BEGIN
SELECT col1 FROM TABLE WHERE id = param_id;
END;
$BODY$
LANGUAGE plpgsql;
I would like to avoid a DECLARE just for this.
Yes you can. There are a number of ways.
1) RETURN (SELECT ...)
CREATE OR REPLACE FUNCTION get_1(_param_id integer)
RETURNS integer
LANGUAGE plpgsql AS
$func$
BEGIN
RETURN _param_id;
-- Or:
-- RETURN (SELECT col1 FROM tbl WHERE id = _param_id);
END
$func$;
2) Use an OUT or INOUT parameter
CREATE OR REPLACE FUNCTION get_2(_param_id integer, OUT _col1 integer)
-- RETURNS integer -- is optional noise in this case
LANGUAGE plpgsql AS
$func$
BEGIN
SELECT INTO _col1 col1 FROM tbl WHERE id = _param_id;
-- also valid, but discouraged:
-- _col1 := col1 FROM tbl WHERE id = _param_id;
END
$func$;
More in the manual here.
3) (Ab)use IN parameter
Since Postgres 9.0 you can also use input parameters as variables. The release notes for 9.0:
An input parameter now acts like a local variable initialized to the passed-in value.
CREATE OR REPLACE FUNCTION get_3(_param_id integer)
RETURNS integer
LANGUAGE plpgsql AS
$func$
BEGIN
SELECT INTO _param_id col1 FROM tbl WHERE id = _param_id;
RETURN _param_id;
-- Also vlaid, but discouraged:
-- $1 := col1 FROM tbl WHERE id = $1;
-- RETURN $1;
END
$func$;
Variants 2) and 3) do use a variable implicitly, but you don't have to DECLARE one explicitly (as requested).
4) Use a DEFAULT value with an INOUT parameter
This is a bit of a special case. The function body can be empty.
CREATE OR REPLACE FUNCTION get_4(_param_id integer, INOUT _col1 integer = 123)
RETURNS integer
LANGUAGE plpgsql AS
$func$
BEGIN
-- You can assign some (other) value to _col1:
-- SELECT INTO _col1 col1 FROM tbl WHERE id = _param_id;
-- If you don't, the DEFAULT 123 will be returned.
END
$func$;
INOUT _col1 integer = 123 is short notation for INOUT _col1 integer DEFAULT 123. See:
The forgotten assignment operator "=" and the commonplace ":="
5) Use a plain SQL function instead
CREATE OR REPLACE FUNCTION get_5(_param_id integer)
RETURNS integer
LANGUAGE sql AS
'SELECT col1 FROM tbl WHERE id = _param_id';
Or use use param reference $1 instead of param name.
Variant 5) one uses plain single quotes for the function body. All the same. See:
What are '$$' used for in PL/pgSQL
Insert text with single quotes in PostgreSQL
db<>fiddle here - demonstrating all (incl. call)