Re:Select Code_execution from * Using SQLite; (2019)
by juped on Saturday June 13, 2020 @06:02PM
(#23513173)
Do you list the unfortunate design baggage somewhere?
Re:Select Code_execution from * Using SQLite; (2019)
by anarazel on Saturday June 13, 2020 @07:45PM
(#23513849)
Not centrally anywhere, as far as I am aware of.
There's a few user visible one that need explicit options to be enabled, and there's documentation for those, of course.
There's other where there's plenty source code level comments explaining the issues.
And some others that "just" are mentioned in discussions.
I can come up with examples if you're interested.
Yea, that made it harder in the past for other test tooling too. IIRC Greg Stark fuzzed our regex library and had to fight against the more complicated interaction due to client / server to make that work. Ended up finding quite a few things...
> (3) SQLite has much stronger backwards compatibility guarantees than PostgreSQL. We have to continue to support design errors made decades ago, whereas PostgreSQL gets to walk away from their poor design choices with each major release. For this reason, SQLite is rather more complicated than you might imagine.
FWIW, we (pg devs) are pretty hesitant to break backward compat. Sure, each release has a few things, but it's usually pretty corner case-y stuff. Check e.g. the list for the upcoming v13: https://www.postgresql.org/docs/13/release-13.html
There's a lot of significant design errors we're continuing to support just because it'd be too painful to break compat.