Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NamedExec issues expanding VALUES #898

Open
nicjohnson145 opened this issue Oct 12, 2023 · 3 comments
Open

NamedExec issues expanding VALUES #898

nicjohnson145 opened this issue Oct 12, 2023 · 3 comments

Comments

@nicjohnson145
Copy link

When populating a values statement with multiple entries, certain query shapes are not expanding as expected. This can be shown with the following example

stmt := `
	INSERT INTO
		foo_table
	VALUES
	(
		:id,
		:foo,
		:bar
	)
`
args := []map[string]any{
	{
		"id": 1,
		"foo": "foo1",
		"bar": "bar1",
	},
	{
		"id": 2,
		"foo": "foo2",
		"bar": "bar2",
	},
}

_, err := db.NamedExec(stmt, args)

If foo_table has 3 columns (or any remaining columns are defaulted) then this is a legal insert statement. Instead this fails with an error similar to

pq: got 6 parameters but the statement requires 3

This is easy enough to work around in the case of an insert, just specify the columns. However this is impossible to work around in the case of an UPDATE ... FROM statement.

	UPDATE
		foo_table f
	SET
		foo = v.foo
	FROM (
		VALUES
		(:id, :foo)
	) AS v ( id, foo )
	WHERE
		f.id = v.id

I believe this is due to the regex here which incorrectly requires that a values statement be preceeded by a closing parenthesis, so the values statements do not get duplicated in the above cases.

@mw9000
Copy link

mw9000 commented Oct 31, 2023

@nicjohnson145 it's a hacky workaround, but you can satisfy the regex with a commented out right parenthesis.

	UPDATE
		foo_table f
	SET
		foo = v.foo
	FROM (
                --)
		VALUES
		(:id, :foo)
	) AS v ( id, foo )
	WHERE
		f.id = v.id

@nicjohnson145
Copy link
Author

@mw9000 oof. that is terrible. But it's arguably less terrible than the "dont use named statements, and instead manually specify values lists and do parameter list flattening" that I'm doing right now to work around this. Thanks for the suggestion 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants