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 whyIf 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:
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?
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
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
