Skip to content

Conversation

@covrom
Copy link

@covrom covrom commented Jun 2, 2018

return ODBC typename for columns in sql.Column.DatabaseTypeName()

@alexbrainman
Copy link
Owner

Why do you need this function?

How it is helpful to you?

Who will maintain this function in the future? Imagine that I tomorrow I will add more column types.

Thank you.

Alex

@covrom
Copy link
Author

covrom commented Jun 2, 2018

Why do you need this function?

Programmers, who need usage sql.Column.DatabaseTypeName() method of sql.Column interface.

How it is helpful to you?

I can see, what type of value is in []byte slice. By example, SQL_C_CHAR or SQL_C_WCHAR. I can convert it from and to local language codepage or utf8.

Who will maintain this function in the future?

This types defined in ODBC. If you add new type tomorrow, you must add string representation, in all cases (by example if you switch from int codes of types to interface with String() and Code() methods).

@alexbrainman
Copy link
Owner

Thank you for explaining.

I don't see your changes useful to me. The change looks just like an extra code that I have to maintain for no benefit to me.

I will not merge your change. I suggest you keep this code in your version of this package.

Sorry.

Alex

@hugorut
Copy link

hugorut commented Oct 12, 2018

I'm a plus one on wanting this implemented. However I don't think this actually goes far enough. For our use case I need most of the additional sql.Rows interfaces implemented in the odbc package:

  • driver.RowsNextResultSet
  • driver.RowsColumnTypePrecisionScale
  • driver.RowsColumnTypeNullable
  • driver.RowsColumnTypeLength
  • driver.RowsColumnTypeDatabaseTypeName

I am happy to put a PR in for this. However, I wanted to test the water first @alexbrainman as you seem like you don't want to maintain a solution for this. I'll outline my case and you can decide if you think the PR is warranted.

The main reason for adding this functionality is for use with rows.ColumnTypes() method. Currently this method does explicit type checking to return underlying results:

func rowsColumnInfoSetupConnLocked(rowsi driver.Rows) []*ColumnType {
    ...
    if prop, ok := rowsi.(driver.RowsColumnTypeScanType); ok {
        ci.scanType = prop.ColumnTypeScanType(i)
    }
    ...
}

We need ColumnTypes as our system defines a global schema to import from multiple datasources. i.e. We need to translate the underlying sql.ColumnType & sql.ScanType, e.t.c. to our predefined types. The ColumnTypes method defines a nice interface for doing this and remains consistent across our codebase.

Let me know thoughts, I understand your hesitation to not maintain.

@alexbrainman
Copy link
Owner

I'm a plus one on wanting this implemented. However I don't think this actually goes far enough.

Sorry for pushing this back. But I have no free time to maintain more changes in this repo. You would have to fork this package and make changes there.

Alex

@hugorut
Copy link

hugorut commented Oct 12, 2018

Ok no problems. Thanks for the response.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants