Dynamic type parameters: Cannot cast System.Int32 into any valid DbType after upgrading from to #201

gdau opened this Issue Mar 28, 2014 · 9 comments


None yet

4 participants

gdau commented Mar 28, 2014


After upgrading to I am getting an error "Can't cast System.Int32 into any valid DbType." originating from the setter "public override Object Value" within NpgsqlParameter.cs.

I am using dapper.net and I have calls like this:

var template = builder.AddTemplate(@"
LIMIT :limit",
    limit = null as object

This is stripped-down so doesn't necessarily make sense in this context, but I can fix it if I change

limit = null as object


limit = null as Int32?

Is the previous method supported? I just wanted to make sure this is by-design before I go about changing all the places where this is used. I have confirmed that in this code works 100%.

Kind Regards,



Hmmmmm, thus isn't right. It should work. Do you think it would be possible to get how dapper is setting the parameter value? I never used dapper but I will try to set it up so I can try to reproduce this problem.
Thanks in advance.

gdau commented Mar 29, 2014


Thanks for getting back to me. I have attached a very simple console app that repro's this issue (you only need to put in your own connection string and any valid table name inside Program.cs).

If you change the reference to use the version of npgsql inside the included "original_working_lib" folder you will see the same code works fine (

You can download the sample app from here:


Thanks for taking a look.



Thanks for your test, @gdau !

But I got an even simpler test case which shows the problem:

NpgsqlParameter p = new NpgsqlParameter();
p.DbType = DbType.Object;

p.Value = 1;

I'm checking that.

It seems to have been caused by this commit: eeed751


Hi, @glenebob , I noticed that this problem is caused by the fact that when setting a parameter value, Npgsql tries to check the type of the parameter.

This code is having problem in the following line:

if (backendTypeInfo == null && !NpgsqlTypesHelper.TryGetBackendTypeInfo(type_info.Name, out backendTypeInfo))

It seems that the NpgsqlTypesHelper.TryGetBackendTypeInfo isn't finding the corresponding typeinfo. This name is text_nonbinary.

I notice that when you set the dbtype of the parameter to DbType.Object, Npgsql is setting the typeinfo to a type called text_nonbinary:

nativeTypeMapping.AddType("text_nonbinary", NpgsqlDbType.Text, DbType.Object, true);

which doesn't have a correspondence in the backend type info and thus it is throwing the exception.

Can you, please, talk more about this text_nonbinary mapping? Thanks in advance.


Hi, @glenebob !

I tested here and using one of your fixes from #102 ( using "unknown" instead of "text_nonbinary" ) fixes this issue (201).

Do you want to create a pull request to fix #201 or can I create one?

glenebob commented Apr 4, 2014

I can do that this weekend. I'll be working in Npgsql a little. I need
to back port those recent query rewrite fixes to 2.1.


On Fri, Apr 4, 2014 at 12:57 PM, Francisco Figueiredo Jr. <
notifications@github.com> wrote:

Hi, @glenebob https://github.com/glenebob !

I tested here and using one of your fixes from #102#102 using "unknown" instead of "text_nonbinary" ) fixes this issue (201).

Do you want to create a pull request to fix #201https://github.com/npgsql/Npgsql/issues/201or can I create one?

Reply to this email directly or view it on GitHubhttps://github.com/npgsql/Npgsql/issues/201#issuecomment-39604997


Great! I'm also investigating the #146
I'll let you know when I find anything. I already found somethings about it and added my comments there. If you can have a look at them, it would be awesome!

@franciscojunior franciscojunior added this to the 2.2 milestone Apr 8, 2014
danzel commented May 6, 2014

Here is a bunch of test cases:

@danzel danzel added a commit to danzel/Npgsql that referenced this issue May 6, 2014
@danzel danzel 'fix' for #201 maybe 85236fe
@drunaar drunaar added a commit to drunaar/Npgsql that referenced this issue May 14, 2014
@danzel @drunaar danzel + drunaar 'fix' for #201 maybe 0349893

Fixed by #230 .

@franciscojunior franciscojunior added the bug label Jun 9, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment