On Fri, Dec 13, 2024 at 6:53 AM Niklas Hambüchen <mail@nh2.me> wrote:
If I build some workaround today, e.g. splitting the query into multiple ones of max length N, how do I know it will still work in the future, e.g. if Postgres changes the Bison version or switches to a different parser?
If you work-around it by doing "create temp table" and "copy as many rows into as you'd like" the reality of the limit here disappears.
You also gain the added benefit of having less potential exposure to SQL-injection by using a code path that doesn't require placing many potentially user-supplied string literals into a query body.
In some ways this is a design choice that encourages the user to write a better query form that the system has been optimized around.
I don't disagree with the premise that such hard-coded limits are undesirable but they also aren't always worth getting rid of, especially if they are inherited from an upstream dependency.
