David E. Wheeler wrote:
On Sep 8, 2009, at 11:05 AM, Greg Sabino Mullane wrote:
Right. I looked into this some time back, and made a rough proof of
concept,
but there was some big problem I ran into. Cannot remember at the moment
what it was. <...ponders...> Oh right, I think it was just the
complication
that at the time you encounter an unknown type, you are already
knee-deep in
the middle of a fetch run, so making a separate call right then to
the backend
to ask it for information about that type is not possible. One
solution would
be to have a flag that makes DBD::Pg grab info about all custom types
on startup
(which has an associated cost). Another would be to have it abort the
current
fetch, grab the custom info, cache it, then re-run the query. A third
would be
to have a special command that you can run to have it grab the custom
type
information on demand.
The first solution is the one I was thinking of.
The trouble is that every table has a composite type and associated
array type created for it. I think you would want something more fine
grained than that. Something like:
$dbh->fetch_type_info(qw(list of type names));
Maybe make it a connection parameter too.
cheers
andrew
