PostgreSQL: Parameter substitution for LISTEN?
up vote
1
down vote
favorite
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.
postgresql security sql-injection
add a comment |
up vote
1
down vote
favorite
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.
postgresql security sql-injection
See Proper insertion of table name.
– klin
Nov 21 at 0:38
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
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.
postgresql security sql-injection
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.
postgresql security sql-injection
postgresql security sql-injection
edited 2 days ago
Laurenz Albe
41.7k92746
41.7k92746
asked Nov 21 at 0:03
mic_e
2,60812235
2,60812235
See Proper insertion of table name.
– klin
Nov 21 at 0:38
add a comment |
See Proper insertion of table name.
– klin
Nov 21 at 0:38
See Proper insertion of table name.
– klin
Nov 21 at 0:38
See Proper insertion of table name.
– klin
Nov 21 at 0:38
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
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.
Why%L
? Does it ensure safe escaping?
– mic_e
2 days ago
Yes; I have added another line and a link to my answer.
– Laurenz Albe
2 days ago
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
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.
Why%L
? Does it ensure safe escaping?
– mic_e
2 days ago
Yes; I have added another line and a link to my answer.
– Laurenz Albe
2 days ago
add a comment |
up vote
1
down vote
accepted
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.
Why%L
? Does it ensure safe escaping?
– mic_e
2 days ago
Yes; I have added another line and a link to my answer.
– Laurenz Albe
2 days ago
add a comment |
up vote
1
down vote
accepted
up vote
1
down vote
accepted
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.
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.
edited 2 days ago
answered 2 days ago
Laurenz Albe
41.7k92746
41.7k92746
Why%L
? Does it ensure safe escaping?
– mic_e
2 days ago
Yes; I have added another line and a link to my answer.
– Laurenz Albe
2 days ago
add a comment |
Why%L
? Does it ensure safe escaping?
– mic_e
2 days ago
Yes; I have added another line and a link to my answer.
– Laurenz Albe
2 days ago
Why
%L
? Does it ensure safe escaping?– mic_e
2 days ago
Why
%L
? Does it ensure safe escaping?– mic_e
2 days ago
Yes; I have added another line and a link to my answer.
– Laurenz Albe
2 days ago
Yes; I have added another line and a link to my answer.
– Laurenz Albe
2 days ago
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53403450%2fpostgresql-parameter-substitution-for-listen%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
See Proper insertion of table name.
– klin
Nov 21 at 0:38