db: modify mysql/pg/sqlite interface for pool working

[kbkpbot]

breaking, for an unified close function needed by the pool interface :

1. mysql : modify reset()!bool => reset()!, close()=>close()!
2. pg: modify close() => close()!
3. sqlite: modify close()!bool => close()!

An example added.

[huly-for-github]

Connected to Huly®: V_0.6-23196

[enghitalo]

Can't vlib/db/*/pool be deprecated in order to be replaced by vlib/pool?

[JalonSolov]

Probably... once vlib/pool is stabilized (and this PR will help with that).

[medvednikov]

In Go the builtin DB interfaces use pools by default.

It was my mistake not doing this when designing the original DB interfaces in V.

We definitely should use DB pools by default.

Go's standard library database/sql package is specifically designed to be used concurrently and is goroutine-safe when used correctly. You don't need to add mutexes or other complex synchronization primitives around your database calls yourself.

When you call sql.Open(), you are not getting a single database connection. You are getting a handle to a pool of database connections. This sql.DB object is a long-lived object that manages these connections for you.

Here's how it works under the hood when a request comes in:

    A goroutine (handling an HTTP request) needs to talk to the database.

    It calls a method on the shared sql.DB object, like db.QueryContext() or db.ExecContext().

    The sql.DB pool checks if there is an idle connection available.

        If yes, it gives that connection to the current goroutine.

        If no, and the pool isn't at its maximum size, it creates a new connection.

        If no, and the pool is full, the goroutine waits until a connection is returned to the pool.

    The goroutine performs its database operation (query, insert, etc.).

    When the operation is finished (specifically, when you call rows.Close() or the statement finishes executing), the connection is returned to the pool, ready to be used by another goroutine. It is not closed.

This mechanism makes database access both efficient (reusing connections) and safe for concurrent use.

[medvednikov]

That also means we won't need a public ConnectionPool struct in the API. Since the pools are always used by default.

[JalonSolov]

markdown module still needs an update, but it'll have to be done after this is merged. The classic chicken/egg problem. :-\

[Jengro777]

https://github.com/vlang/v/blob/master/vlib%2Fdb%2Fmysql%2Fpool.v

This very concise pool should be deleted.
Too many pools affect new people's judgment.

[Jengro777]

#23995

[einar-hjortdal]

I want firebird to use the connection pool, but I do not see any public DB interface to satisfy. Am I missing something or is this exclusively for internal sql libraries?

[spytheman]

Search for interface in vlib/pool .

[spytheman]

https://github.com/vlang/v/blob/master/vlib/pool/connection.v#L10