Re: Implementing "thick"/"fat" databases - Mailing list pgsql-general

From Chris Travers
Subject Re: Implementing "thick"/"fat" databases
Date
Msg-id CAKt_ZftELMG-Lxa9DQkWbWR4mXp3xgJ-nsXS7DQCdEMb4xVqNA@mail.gmail.com
Whole thread Raw
In response to Re: Implementing "thick"/"fat" databases  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: Implementing "thick"/"fat" databases  ("Karsten Hilbert" <Karsten.Hilbert@gmx.net>)
Re: Implementing "thick"/"fat" databases  ("Karl Nack" <karlnack@futurityinc.com>)
List pgsql-general
On Wed, Jul 27, 2011 at 7:01 AM, Merlin Moncure <mmoncure@gmail.com> wrote:

> Note, we wrote libpqtypes (http://libpqtypes.esilo.com/) precisely to
> deal with this problem -- first class handling of arrays and
> composites in the client.  It's not much help for a perl client, but I
> think similar methodologies can be made for most languages. Sending
> rich data structures directly to procedures in the database transforms
> the way the application/database communications work for the better.
> It's new and weird to many developers, especially those trained on ORM
> usage patterns, but is also entirely effective.
>
Cool :-)

As I understand it DBD::Pg has excellent handling of both these things
too.  The reason we are not doing more with the composite types yet is
because we currently support versions of DBD::Pg which support arrays
well but not the composite types, though that will probably change in
1.4.

I wonder which other languages have first class support for these areas of Pg?

Best Wishes,
Chris Travers

pgsql-general by date:

Previous
From: Willy-Bas Loos
Date:
Subject: does slony use work_mem?
Next
From: "Karsten Hilbert"
Date:
Subject: Re: Implementing "thick"/"fat" databases