From: | Andrew McNamara <andrewm(at)object-craft(dot)com(dot)au> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Confusion over Python drivers |
Date: | 2010-02-08 23:46:54 |
Message-ID: | 20100208234654.2F62C206F9@longblack.object-craft.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>On Tue, 2010-02-09 at 09:15 +1100, Andrew McNamara wrote:
>> I can't see how this would work with binary query parameters - the server
>> will see a blob of binary data and have no way to know what it represents.
>
>Unknown is unknown, whether in binary or text format. As far as I know,
>PostgreSQL never looks inside a literal of unknown type to try to
>determine its type -- it only looks at the context (to what function is
>it an argument?).
>
>For instance:
>
> SELECT '5'; -- has no idea what type it is
>
> SELECT '5' + 1; -- it's an int
>
> SELECT 'a' + 1; -- it's still an int
> ERROR: invalid input syntax for integer: "a"
> LINE 1: SELECT 'a' + 1;
>
> SELECT '5.0' + 1; -- still an int, bad input format
> ERROR: invalid input syntax for integer: "5.0"
> LINE 1: SELECT '5.0' + 1;
The problem is deeper than that - when query parameters use the binary
option, the server has no way to decode the binary parameter without an
appropriate type OID.
As you say, postgres will cast types depending on context, however this
is stricter when binary parameters are used (because they only have one
valid interpretation, whereas a text parameter may have several).
--
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2010-02-08 23:50:53 | Re: Confusion over Python drivers |
Previous Message | Jeff Davis | 2010-02-08 23:34:25 | Re: Confusion over Python drivers |