Re: [go-nuts] Re: General question: complex search form and query params

> > Unless I'm misunderstanding something, that kind of string concatenation > looks dangerous to me. This approach may be error prone so testing is important but I believe the database/sql placeholders avoid any SQL injection. Here the caller also has responsibility to validate the input (su

Re: [go-nuts] Re: General question: complex search form and query params

Unless I'm misunderstanding something, that kind of string concatenation looks dangerous to me. I'v been doing a bit of digging... Turns out there is a DSL that looks like what I'm looking for: the Lucene query syntax . Some variant of

[go-nuts] Re: General question: complex search form and query params

Mapping a subset DSL to SQL doesn’t sound too difficult since SQL already has those boolean expressions and such. The database/sql library uses context for cancellation, so queries that take too long could be cancelled by a timer goroutine. One thing for me that would be helped by a library is

[go-nuts] Re: General question: complex search form and query params

> > I believe correctly used database/sql (with the argument placeholders) > protects against SQL injection > Yeah I badly explained this, an SQL builder solves security *AND* flexibility for me. Standard database/sql placeholders are too painful when the user params are too complex, and I can

[go-nuts] Re: General question: complex search form and query params

> > To prevent SQL injection and for flexibility, I'm set on using an sql > builder library. I believe correctly used database/sql (with the argument placeholders) protects against SQL injection. There’s a query builder for postgres with MIT license posted here a few days ago: https://groups