Re: Composite types and tables - when to use?

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Postgres User <postgres(dot)developer(at)gmail(dot)com>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Composite types and tables - when to use?
Date: 2009-10-06 20:59:54
Message-ID: b42b73150910061359v6ae837f7k58d0679f916b9f5b@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, Oct 6, 2009 at 4:43 PM, Postgres User
<postgres(dot)developer(at)gmail(dot)com> wrote:
> Browsing the docs last night, I realized that I've never taken
> advantage of Postgres' powerful composite types.  But a question came
> to mind- in what scenarios should you use a composite type in a table
> structure?  That is, I can see the benefits of a composiite type
> insofar as it essentially lets you add virtual  tuples to a table
> without having to alter the table structure to add new fields.
> Instead you can simply extend the composite type.  But why take this
> approach?

First, a quick clarification. You can only alter composite types if
they are defined with 'create table', not 'create type as'. For this
reason, I always create my composites with 'create table'.

Using composites inside a table structure can be useful but is easily
abused. There are useful cases though: the built in geo types are all
basically composite types, in that they are grouped POD types. The
rules of thumb for using composite/array inside a table are:

*) Are you sure you are not adding structure for no reason?
*) Does your data always get written/read at the same time?
*) If you were to, say, use a foreign key, would you link it to the
composite itself and not its inner fields?
*) Do you not care that related changes elsewhere in the schema can
give you major headaches?
*) Does your data naturally group in a way such that it feels like a
single element?
*) Does your client app have ability to deal with composites without
dealing with (much nastier than you think) parsing?

If you answered 'yes' to all of the above, maybe a composite type (or,
in similarly, an array) is worth considering. Composites work
absolute wonders in passing data to/from functions, and can be useful
for lots of other things.

Just a heads up: if you are writing your application in C and are
looking for an effective way of dealing with composites in the client,
check out libpqtypes (http://pgfoundry.org/projects/libpqtypes/) No
parsing! :-).

merlin

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Scott Mead 2009-10-06 21:11:57 Re: pg_dumpall asking for password for each database
Previous Message Krzysztof Barlik 2009-10-06 20:59:32 pg_dumpall asking for password for each database