Haha, that's pretty clever 😉 One caveat though: I think the reason why the PRAGMA is write-only is that there aren't just those two LIKE functions (case-sensitive and case-insensitive). Instead you can have any function as the LIKE operator by just registering it in the application or via an extension as described here. So I guess the PRAGMA sets the LIKE function to one of the two implementations that come with SQLite but because you can set it to an altogether different function from an extension it's not feasible to read from the PRAGMA. And with your approach we can't find out either if it's not a third function from some extension. So what do you reckon is better: just merging this anyway because it'll work most of the time or leave it out to avoid confusion here? I'm fine with either but when merging it we should add a comment in the code as well as a tooltip or something in the UI.

Hmmm, let's merge it and see how it goes in actual use? 😄

@MKleusberg You're probably right about why this pragma is write-only. Though it would make sense to implement a read interface returning ON, OFF, OTHER. The OTHER value would not be accepted in the write. But anyway, the pragma seems useful and I think we could add an information tooltip over the value: Warning: this pragma is not readable and this value has been inferred. Writing the pragma might overwrite a redefined LIKE provided by an SQLite extension.

The only way to have a redefined LIKE is by the user having loaded an extension through DB4S, isn't? In that case it would be possible to know in most cases whether that is a problem at all.

Yep, that warning sounds right. Want to add it and then merge this?

Yep, that warning sounds right. Want to add it and then merge this?

Of course.

Awesome, I'll merge this then 😄