Please modify driver's registration logic.

[awly]

Please modify driver's registration logic.
If I want to work with database/sql package only (which in my opinion is the "better" way) currently I have to add
import _ "github.com/bmizerany/pq"
to trigger pq's init() to call the driver registration on line 33.

I believe that _ imports are in general "bad" as a design decision, and using standard go's lib's sql package is the preferred way to work with sql databases.

At the very least, please put a note in the readme to avoid confusion caused by the lack of (exported) Driver.

Proposed solutions:

• export the driver, remove sql.Register from init()
• add explicit func Register(), remove sql.Register from init()
• leave as is, but document somewhere

[fdr]

The current style is not going away, because I'm not going to break programs that have done this. In cases of things like these, what's the current idiom used in other driver implementations? For things like these it's basically most important to be most like what everyone else is doing. I was under the impression at the time that pq was written that side effects from a blank import was considered an acceptable option for 'plugin'-style behavior.

[bmizerany]

The current, and correct, practice is to interface with database/sql
after registering the driver through importing the driver. The _ signals
the current file only intendeds to benefit from the packages side affects.
Some wish to use helper functions in the pq package, so they omit the _.

All of this is modeled after examples and tests provided by the
database/sql package.

On Wednesday, January 16, 2013, cr0n wrote:

Please modify driver's registration logic.
If I want to work with database/sql package only (which in my opinion is
the "better" way) currently I have to add
import _ "github.com/bmizerany/pq"
to trigger pq's init()https://github.com/bmizerany/pq/blob/master/conn.go#L32to call the driver registration on line 33.

I believe that _ imports are in general "bad" as a design decision, and
using standard go's lib's sql package is the preferred way to work with sql
databases.

At the very least, please put a note in the readme to avoid confusion
caused by the lack of (exported) Driver.

Proposed solutions:

• export the driver, remove sql.Register from init()

• add explicit func Register(), remove sql.Register from init()

• leave as is, but document somewhere

  —
  Reply to this email directly or view it on GitHubhttps://github.com/bmizerany/pq/issues/71.

[fdr]

Well, I think that's pretty authoritative. Unless there is evidence of a new idiom and clear deficiency, I think this matter is closed. If you think a terse doc patch will help, please submit a pull request.

[gabsn]

I am currently a wrapper for database/sql and like @awly said, you should at least export the driver, so that we can wrap it.

[tamird]

@gabsn that's already done #585.