Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upAllow for ad-hoc table CTEs with parameterized data #304
Conversation
|
just a +1 |
f9a6417
to
a30bb49
eyaldar
commented
Jul 14, 2020
|
Any plans to push this one? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
freakingawesome commentedOct 8, 2019
This addresses the request in #152 by adding a
With(...)variation that takes a list of column names and a list of list of values to create a CTE representation of that data. That CTE can then be used in subsequent SELECT statements to, for example, query efficiently against a number of composite keys.Here is an example for creating a CTE with two rows of parameterized data:
This conceptually results in a CTE whose contents are:
The default SQL implementation uses a number of
SELECTstatements joined byUNION ALL:Postgres Output:
SQL Server output uses its own
VALUES (...), (...)syntax:Note: The initial issue #152 showed that Postgres has its own syntax for ad-hoc tables in a CTE, but I did not implement that specific flavor because it would involve more substantial changes to the actual
WITHportion of the CTE, e.g.WITH cte (a, b, c) AS (...). Postgres instead uses theUNION ALLflavor