FAQ
I'm trying to write a tool that processes the results of arbitrary
user-supplied database queries using a database/sql driver. Unfortunately,
that makes calling Rows.Scan() problematic, because I don't know what I
should be scanning into. I'm sure this is atypical, but it does
happen--consider a database admin tool that needs to run user-supplied
queries and display results. Other database APIs offer some way of getting
type information [1], but as far as I can tell, in database/sql, I only
have Rows.Columns(), which only gives me the column names. Could a
Rows.ColumnTypes() be added? What could it return? It seems the most
flexible implementation would have to return some identifier of the
internal database type, rather than the expected Go type (since otherwise
this clashes with the Scanner design).

[1]: e.g.,
http://docs.oracle.com/javase/7/docs/api/java/sql/ResultSetMetaData.html#getColumnClassName(int)

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Daniel Theophanes at Jul 7, 2014 at 4:04 am
    This has been discussed in the past, but I don't think this will happen in
    "database/sql". I've started a new driver interface here:
    http://godoc.org/bitbucket.org/kardianos/rdb#Column

    The design is intended to work well in frameworks that need this
    information. For my use case it is working well, though I only have one
    fully operational driver right now. I hope to add a PG driver soon. If you
    are interested, I'd love to also get an Oracle driver using their
    (gigantic) C DLL. Feedback or design suggestions welcome.

    -Daniel

    On Sunday, July 6, 2014 2:34:04 PM UTC-7, Maciek Sakrejda wrote:

    I'm trying to write a tool that processes the results of arbitrary
    user-supplied database queries using a database/sql driver. Unfortunately,
    that makes calling Rows.Scan() problematic, because I don't know what I
    should be scanning into. I'm sure this is atypical, but it does
    happen--consider a database admin tool that needs to run user-supplied
    queries and display results. Other database APIs offer some way of getting
    type information [1], but as far as I can tell, in database/sql, I only
    have Rows.Columns(), which only gives me the column names. Could a
    Rows.ColumnTypes() be added? What could it return? It seems the most
    flexible implementation would have to return some identifier of the
    internal database type, rather than the expected Go type (since otherwise
    this clashes with the Scanner design).

    [1]: e.g.,
    http://docs.oracle.com/javase/7/docs/api/java/sql/ResultSetMetaData.html#getColumnClassName(int)
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Arne Hormann at Jul 7, 2014 at 4:29 pm
    @Maciek maybe you could give https://github.com/arnehormann/sqlinternals a
    look, I told you about it here:
    https://groups.google.com/forum/#!topic/golang-nuts/eZmWzURD-Uo
    It *should* be pretty easy to adapt it to PostgreSQL (that's still what
    you're using, right?), I just lack the experience myself.
    Have a look at the mysql package inside to see how it's used. The code is
    (very) short.
    I just crack open the database/sql wrapper struct and access the driver's
    implementation of database/sql/driver.Rows, which will probably contain
    everything you need.

    I posted a concept to solve this in database/sql here:
    https://groups.google.com/forum/#!searchin/golang-dev/database$2Fsql/golang-dev/0CM5MKbiQPs/3vRAFpvf_agJ
    This is the issue I opened:
    https://code.google.com/p/go/issues/detail?id=5606

    @Daniel I apologize for failing to deliver on my promise to review your
    code.
    I had a deeper look at it and it appears solid and thought through, but it
    is too detailed for my taste.
    I still think it's best to move more functionality surpassing the basic use
    cases to the drivers.

    Cheers,
    Arne

    Am Montag, 7. Juli 2014 06:04:21 UTC+2 schrieb Daniel Theophanes:
    This has been discussed in the past, but I don't think this will happen in
    "database/sql". I've started a new driver interface here:
    http://godoc.org/bitbucket.org/kardianos/rdb#Column

    The design is intended to work well in frameworks that need this
    information. For my use case it is working well, though I only have one
    fully operational driver right now. I hope to add a PG driver soon. If you
    are interested, I'd love to also get an Oracle driver using their
    (gigantic) C DLL. Feedback or design suggestions welcome.

    -Daniel

    On Sunday, July 6, 2014 2:34:04 PM UTC-7, Maciek Sakrejda wrote:

    I'm trying to write a tool that processes the results of arbitrary
    user-supplied database queries using a database/sql driver. Unfortunately,
    that makes calling Rows.Scan() problematic, because I don't know what I
    should be scanning into. I'm sure this is atypical, but it does
    happen--consider a database admin tool that needs to run user-supplied
    queries and display results. Other database APIs offer some way of getting
    type information [1], but as far as I can tell, in database/sql, I only
    have Rows.Columns(), which only gives me the column names. Could a
    Rows.ColumnTypes() be added? What could it return? It seems the most
    flexible implementation would have to return some identifier of the
    internal database type, rather than the expected Go type (since otherwise
    this clashes with the Scanner design).

    [1]: e.g.,
    http://docs.oracle.com/javase/7/docs/api/java/sql/ResultSetMetaData.html#getColumnClassName(int)
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Andy Balholm at Jul 8, 2014 at 1:27 am
    Don't forget that you can scan into an interface{} and get whatever type the driver returned.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Maciek Sakrejda at Jul 8, 2014 at 6:22 am
    Daniel:

    Interesting! I definitely think database/sql can be improved upon, although
    I find that most database abstraction layers are a
    lowest-common-denominator straitjacket, and one should embrace
    database-dependence (and abstract at the application data persistence
    layer), so I'm probably not the right person to review rdb. From a brief
    glance, it certainly looks more complete than database/sql and more like
    the JDBC API (which, while sometimes cumbersome, is definitely more
    powerful).

    Arne:

    I remember that now, thanks! sqlinternals looks neat. I figured out another
    way to do what I want (see below), so I probably won't use it here, but
    thanks anyway.

    Andy:

    Actually, that's basically what I ended up doing. Thanks for the suggestion.


    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJul 6, '14 at 9:33p
activeJul 8, '14 at 6:22a
posts5
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase