| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Andrew McNamara <andrewm(at)object-craft(dot)com(dot)au> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Confusion over Python drivers |
| Date: | 2010-02-09 00:01:55 |
| Message-ID: | 1265673715.29919.2491.camel@jdavis |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 2010-02-09 at 10:46 +1100, Andrew McNamara wrote:
> 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.
Postgres does not attempt to decode anything (text or binary format)
until it figures out what type it is.
> 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).
Type casts are a different matter; they are only done after the unknown
literals' types have been determined:
create table n(i int);
-- insert numeric literal, which is cast to int (assignment cast)
insert into n values(5.0); -- succeeds
-- insert unknown literal, which is inferred to be of type int
insert into n values('5.0'); -- fails on integer type input function
ERROR: invalid input syntax for integer: "5.0"
LINE 1: insert into n values('5.0');
Can you provide a concrete example in which the text versus binary
format changes the type inference behavior?
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2010-02-09 00:35:43 | Re: Order of operations in lazy_vacuum_rel |
| Previous Message | Jeff Davis | 2010-02-08 23:50:53 | Re: Confusion over Python drivers |