Re: select statement fails - Mailing list pgsql-general

From Andrus
Subject Re: select statement fails
Date
Msg-id fti5i4$2joc$1@news.hub.org
Whole thread Raw
In response to select statement fails  ("Andrus" <kobruleht2@hot.ee>)
Responses Re: select statement fails  (Richard Huxton <dev@archonet.com>)
List pgsql-general
> ALTER TABLE...ALTER COLUMN...TYPE will do it within one statement. It will
> require a lock on the table though.

1. This is part of composite primary key. It is discriminator column and
cannot contain empty string, only single char is allowed.
2. I'm afraid that this will broke existing applications.

So I'm not sure that it is reasonable to make such change.

>> I is more reasonable to force npgsql driver to generate other code if no
>> other solution.
>> npgsql driver wants to add explicit casts to parameters.
>> Is it reasonable to force driver to generate code
>>
>> select * from test where tc=' '::char(1);
>>
>> for char parameter type ?
>
> I'd say so - I presume it just needs to be taught about different types of
> text. Presumably it already knows that int8 is different from int4, so
> it'll be doing something similar already.

Should it cast to char(1) or varchar(1) ?
Driver cannot determine this form .NET type char.
So this seems not possible without providing additional meta information to
driver, i.e. standard ADO .NET interface cannot used.

So I think that only solution is to create this query using string
concatenation and possibly open it to sql injection attacks, parameter
replacement is not possible.

> Check if there is a mailing-list for the npgsql project and ask there -
> someone might already be working on it.

Done.

Andrus.



pgsql-general by date:

Previous
From: "Albe Laurenz"
Date:
Subject: Re: How does psql actually implement the \d commands
Next
From: Ivano Luberti
Date:
Subject: begin transaction locks out other connections