On Monday, November 18, 2002, at 08:58 AM, Tom Lane wrote:
> Thinking about this, it occurs to me that there's no good reason why
> we couldn't allow parameter symbols ($n) to be considered type UNKNOWN
> initially. The type interpretation algorithms would then treat them
> just like quoted literal constants. After parsing finishes, PREPARE
> could scan the tree to see what type each symbol had been cast to.
> (You'd have to raise an error if multiple appearances of the same
> symbol
> had been cast to different types, but that'd be an uncommon case.)
>
> This form of PREPARE would presumably need some way of reporting back
> the types it had determined for the symbols; anyone have a feeling for
> the appropriate API for that?
If I'm understanding you correctly this approach would make it much
easier on dynamic drivers such as DBI and JDBC. Ideally, in DBI, I'd be
able to do something like this:
PREPARE my_stmt AS SELECT foo, bar FROM bat WHERE foo = $1 AND bar = $2;
EXECUTE my_stmt('foo_val', 'bar_val');
It would be the responsibility of the PostgreSQL PREPARE parser to
handle the data typing of $1 and $2, and the responsibility of the DBI
client to pass in data of the appropriate type.
Is this along the lines of what you're thinking, Tom?
Regards,
David
--
David Wheeler AIM: dwTheory
david@wheeler.net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e Jabber:
Theory@jabber.org