Hi all!
Yesterday, 2009-12-12, Josh Cooley committed a better datatype handling mechanism to Npgsql. This will allow Npgsql to be more consistent when handling types because it is now much better defined when to return specific (or provider specific) datatypes and when to return CLR datatypes.
What does all this mean?
Well, Npgsql now implements the methods DbDataReader.GetProviderSpecificValue(), DbDataReader.GetproviderSpecificValues() and GetProviderSpecificDataType().
With those methods implemented, users will have a defined way of getting the specific types provided by Npgsql. The other methods will now always return the CLR types.
This modification will also enable Npgsql to work better with the ado.net library. For example, we have reports that NpgsqlInet data wasn't being rendered in a DataGrid.
By inspecting the test case, the dataset was correctly filled, but Datagrid seemed to not like NpgsqlInet and didn't render its value. With this type handling modification, the data would be returned as an CLR type, maybe an IPAddress or a String which, according to my tests, showed up correctly.
Another solution this modification enable is about support for "interval" npgsql datatype. We have a bug report about that and this modification will fix it too.
This is a big change in the way Npgsql handles data types. We would like you to test it and send us feedback about problems and solutions this change brought. Thanks in advance.
Yesterday, 2009-12-12, Josh Cooley committed a better datatype handling mechanism to Npgsql. This will allow Npgsql to be more consistent when handling types because it is now much better defined when to return specific (or provider specific) datatypes and when to return CLR datatypes.
What does all this mean?
Well, Npgsql now implements the methods DbDataReader.GetProviderSpecificValue(), DbDataReader.GetproviderSpecificValues() and GetProviderSpecificDataType().
With those methods implemented, users will have a defined way of getting the specific types provided by Npgsql. The other methods will now always return the CLR types.
This modification will also enable Npgsql to work better with the ado.net library. For example, we have reports that NpgsqlInet data wasn't being rendered in a DataGrid.
By inspecting the test case, the dataset was correctly filled, but Datagrid seemed to not like NpgsqlInet and didn't render its value. With this type handling modification, the data would be returned as an CLR type, maybe an IPAddress or a String which, according to my tests, showed up correctly.
Another solution this modification enable is about support for "interval" npgsql datatype. We have a bug report about that and this modification will fix it too.
This is a big change in the way Npgsql handles data types. We would like you to test it and send us feedback about problems and solutions this change brought. Thanks in advance.
Comments
I received a Service Unavaiiable error.
I would like to know if the postgresql and npgsql.dll are willing to give support for free or are they expecting an income from.
Did you try our user forums?
forums.npgsql.org
What error are you getting?
I hope it helps.
btw, service unavailable errors can appear on any site. Be it npgsql.com or google.com.
And answering your question, Npgsql and Postgresql already give support for free since the beginning.