On Tue, May 12, 2015 at 04:26:08PM +0100, Tim Bunce wrote:
>     $dbh->{pg_type_mumble} = { $pg_type_id => $pg_type_info, ... };
> 
> Where $pg_type_info contains whatever information DBD::Pg needs to handle
> that data type.
> 
> Then it's no longer DBD::Pg's responsibility to get that information
> on-demand. The application would have the responsibility to provide that
> info for the types it needs to handle. I'd expect one or more modules to
> be developed to gather that info. The info could be cached by the app,
> if appropriate, to avoid refetching on each db connection.

Sounds reasonable.

> Obviously we'd need to discuss what form that information might take.
> The slowest but most flexible option would be to simply provide hooks:
> 
>     $dbh->{pg_type_mumble} = {
>         12345 => {
>             perl_to_pg => sub { ... },
>             pg_to_perl => sub { ... },
>         },
>         ...
>     };
> 
> which would be a handy fallback anyway.
> 
> Some other ideas:
> 
>     12345 => 54321, # treat type 12345 like type 54321
> 
>     pg_to_perl => $PG_TYPE_TREAT_AS_ARRAY, # DBD::Pg exported constant

Having the user know the numeric ids of the types (both theirs and the 
system ones) seems unreasonable - so we could support it, but also allow 
data type names when we can).

I think being able to handle arrays would solve 90% of the current 
problems, so some simple shortcut as you mention above would be 
good, maybe even something like:

$dbh->pg_type_is_array('foobar');

> I wouldn't expect this to do much as it would be implicit:
> 
>     $sth->bind_col(1, \$foo, { pg_type => $pg_type_id });
> 
> but this might be handy to trigger appropriate serialization to postgres:
> 
>     $sth->bind_param(1, $foo, { pg_type => $pg_type_id });

Yeah, that could be another approach, but I like the first (dbh) version 
a little better.

> p.s. I'm not really familar with this part of DBD::Pg or the type
> mechanism in libpq etc so I may be talking nonsense here :)

libpq pretty much stays out of the way except to return us a numeric 
type for each returned column. We map this back to type information 
stored in some structs (see types.c). We look at this when slinging 
the data back and forth to see if we are dealing with an array. Presumably 
we could someday internalize a hash-like mapping for things like hstore 
and json (and even direct mapping to JSON someday).

I still like the idea of auto-discovery by DBD::Pg, maybe just a simple command 
that scans all of the custom types and discovers which are arrays. Perhaps 
to supplement the above. As a one-time per session and on-demand command, 
it shouldn't be too expensive.

-- 
Greg Sabino Mullane [email protected]
End Point Corporation
PGP Key: 0x14964AC8

Attachment: signature.asc
Description: Digital signature

Reply via email to