Roger Pack

I'd think binding to "localhost" would bind to both the ipv4 and ipv6 versions of localhost (ruby seems to have this behavior, but oddly OS X but not linux, weird)....

Yeah 127.0.0.1 would clear things up. I think preferably if you bind to "localhost" it should either bind to "ipv4 over ipv6" (if both are available) or bind to both,...

I'd name it something like 'spawn_in_dedicated_thread' since it doesn't "always" block? Maybe the core functionality would be a 1:1 fiber to thread option?

It seems that if I bring a database down then up (to test this) the pool seems to still recover after about 5 tries (which is of course 5 too...

I thought they had added some background check but not sure . On Friday, February 12, 2021, Stephen von Takach wrote: > did you end up finding a solution for...

So for query parameters it is using a preparedstatement under the covers? On Tue, Apr 5, 2022 at 1:54 PM Johannes Müller ***@***.***> wrote: > crystal-db implicitly uses prepared statements...

Yeah that wasn't super clear...I may do a PR for it. Having "prepared statement" objects might be nice for named parameters, setting parameters separately, etc. but query parameters will work...

For followers, it's like this in Postgres: b = db.build("select $1::int") b.query("2") # no query_one method? `Error: undefined method 'query_one' for PG::Statement (compile-time type is DB::Statement+)` Thanks.

Might be nice if prepared statements could be created in "block form" for auto-closing but maybe since they're manual that's not needed?

actually, just outputting the current column index would be an improvement :)