Repository navigation
Postgres @named parameters don't always work #605
Description
Based on https://github.com/kyleconroy/sqlc/blob/master/docs/named_parameters.md
@foo and sqlc.arg(foo) are identical. However:
-- schema says create table foo ( id bigint );
-- name: demo1 :exec
DELETE FROM foo WHERE id=$1;
-- name: demo2 :exec
DELETE FROM foo WHERE id=@id;
-- name: demo3 :exec
DELETE FROM foo WHERE id=sqlc.arg(id);
results in
$ grep ^func demo.sql.go
func (q *Queries) demo1(ctx context.Context, id sql.NullInt64) error {
func (q *Queries) demo2(ctx context.Context) error {
func (q *Queries) demo3(ctx context.Context, id sql.NullInt64) error {
The @foo form doesn't get recognized in this scenario.
Activity
kyleconroy commentedon Jul 21, 2020
I'm not sure why, but the
@form works when there's a space between the=and@. Take a look here: https://play.sqlc.dev/p/a2beb1f05746a8cac18a0d161645866c83f95896311b1e1b8ad5943199d7c5ddLong term, I think I'm going to regret adding the
@form of named parameters because of issues like this.maxhawkins commentedon Jul 26, 2020
Sorry if this is digging up something that got settled in #71, but I wish the syntax was
:paraminstead of@param. That way you could use psql to debug your queries against a running database:psql --variable "param=1" -f queries.sql databaseUnsure if using that syntax would help with the parsing problem here.
kyleconroy commentedon Aug 28, 2021
@maxhawkins The
:paramsyntax doesn't work with the MySQL parser.tv42 commentedon May 29, 2024
If
@foois not even supposed to work right, https://docs.sqlc.dev/en/latest/howto/named_parameters.html needs to be updated to not recommend it as a shortcut.