On 29 September 2010 20:02, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Peter Bex <Peter.Bex@xxxxxxxxx> writes: >> On Wed, Sep 29, 2010 at 07:33:53PM +0100, Thom Brown wrote: >>> Okay, I understand what's happening. But does the planner need to >>> understand the type of literals in the select list if it's not used >>> anywhere else? > >> Fields sent back to the client also carry their type with them. >> There's no "unknown" type (and it wouldn't be very useful in any >> case, because how would you go about displaying an unknown type?) > > Well, actually there *is* an "unknown" type (OID 705), which is what > will be reported if there's a literal of unresolved type in the SELECT > list. That's how come you can do > > regression=# select 'foo' as meow; > meow > ------ > foo > (1 row) > > However, the issue here is not the output but the input: PREPARE is > complaining that the *input* parameter $1 has no determinate type. > If PREPARE doesn't know it, then the client isn't going to know it > either, and so it would be hard for the client to know what to send > to execute the statement. We'll have to think of ways to work round this then as it's for a database class in a common library we're building. Thanks Tom -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
