Re: Interface for composite types

Greg Sabino Mullane wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
>
>   
>> Having found a case where PostgreSQL's composite types might be useful
>> here, I wonder if support for them could be added to DBD::Pg.
>>     
>
> I spent a lot of time today playing with this, and it looks like it would
> be possible, although it is going to be quite a bear to code: I got
> about 50% there and am going to stop for a while, but thought I should
> report back anyway.
>
> While it would be nice to detect custom types "on the fly", we can't:
> we first learn about them as we're fetching columns, and it's too late
> then to query the system about what the type looks like. So I wrote
> a method $dbh->pg_learn_custom_types(). The idea is that you call this
> at the top of your script, or you pass something to the connect call that
> does it for you first thing.
>
> It does add some overhead, so I'm not comfortable having it automatically
> enabled quite yet. This method basically slurps all the custom type
> information from the system catalogs and stores in internally in a
> C/XS LL struct. When we are fetching and find an unknown type, we walk
> the list of custom types to find a match. If we do find one, we make
> a temporary sql_info_type struct for it and move on. Then we call a
> second internal function for each row, pg_build_hashref(), which recursively
> converts the string returned by Postgres into a glorious nest of hashrefs and
> arrayrefs. Most of all that is written. What's also needed is the reverse
> mapper, to change a bunch of hashrefs into a stringified form to pass to
> PQexec and friends, and some minor bind_param hacks.
>
> All rather rough, and the method names will probably change, but that's the
> basic plan if anyone wants to comment on it.
>
> Very little API changes, except for the learn() call above and probably an
> attribute such as $dbh->{pg_convert_custom_types} which will more than
> likely default to on (or should it simply be on after learn() is called?)
>
>
>   

We really badly need to get better support into libpq for array and 
composite types.

I'm prepared to help if you want to go down that road.

cheers

andrew