On Sun, Aug 24, 2014 at 4:38 PM, Darren Duncan <[email protected]>
wrote:
> Chris, your idea seems good to me in principle, that is when the Postgres
> value is of some composite type, that we support it being automatically
> exposed as a composite value in Perl.
>
> By default I would recommend, keep it simple.
>
> As I recall, DBD::Pg already supports Postgres arrays as Perl arrays, and
> similarly I would recommend supporting composite type values like you
> mention, which are structurally tuples, as Perl hash refs for the members.
>
> For a general form for named composite types, I suggest representing a foo
> like this: "['foo',{bar=>'what',baz=>'ev'}]"; its the simplest form that
> keeps all the information; the 'foo' part could also be generalized to
> however fully-qualified entity names are, eg ['public','foo'] for example.
I would love to see this in DBD::Pg. However there are some complexities
here not present in arrays. Arrays are at least in theory self-contained.
We don't have to ask the db how to parse them. Tuples are not (we need to
do a catalog lookup to find the order of elements).
Do we want that to be memoized? My inclination is maybe the developer
should be in control there but that would also add some complexity there
and possibly a (core) dependency. The dependency doesn't strike me as a
problem but the design decisions do.
So I am thinking this way:
First draft will probably be in my PGObject framework. Once this is
working and stable, I will look at porting the core logic to DBD::Pg. I
won't promise proper Moose handling of things like lazy attributes in this
version, but it should be able to handle hashrefs.
Does that sound like a reasonable plan?
Best Wishes,
Chris Travers
>
>
> -- Darren Duncan
>
>
> On 2014-08-24, 8:07 AM, Chris Travers wrote:
>
>> Hi everyone;
>>
>> I am nearing completion on the logic to serialize composite types into
>> textual
>> representation of tuples for LedgerSMB and I am wondering if there is
>> additional
>> interest from others who use DBD::Pg. If there is we would certainly
>> release
>> the logic and interfaces on CPAN. So I figured I would ask.
>>
>> For those who would be interested, I guess I have a few questions:
>>
>> 1. Do you need Moose or Moo support?
>> 2. Do you need plain old hashref support?
>> 3. Do you need bytea support?
>>
>> If this is unwelcome please ignore but this seemed like a good place to
>> ask
>> since it is PostgreSQL/Perl-specific and many of you might have thought
>> about
>> using composite types in this way.
>>
>> In case it isn't clear what I am talking about is:
>>
>> given a type:
>>
>> CREATE TYPE foo (
>> bar text,
>> baz text
>> );
>>
>> and a hashref {bar => 'foo', baz => 'this, or else that'}
>>
>> it should produce (foo,"this, or else that")
>>
>> --
>> Best Wishes,
>> Chris Travers
>>
>
>
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more
