Re: Working with Array of Composite Type

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Jan de Visser <jan(at)de-visser(dot)net>, <pgsql-general(at)postgresql(dot)org>
Subject: Re: Working with Array of Composite Type
Date: 2015-04-08 00:41:56
Message-ID: 55247954.2080208@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 3/28/15 9:36 AM, Jan de Visser wrote:
> On March 28, 2015 06:18:49 PM Alex Magnum wrote:
>> Hello,
>> I am struggling with finding the right way to deal with arrays of composite
>> types. Bellow is an example of the general setup where I defined an image
>> type to describe the image properties. A user can have mulitple images
>> stored.
>
> The canonical answer is that in almost all cases where you think you want an
> array of composites, you *really* want a table join:
>
> i.e. turn your image *type* into an image *table* with the user_id as a
> foreign key.
>
> CREATE TABLE users (
> user_id serial NOT NULL,
> );
>
> CREATE TABLE image (
> id smallint,
> user_id int references users (user_id)
> caption text,
> is_primary boolean,
> is_private boolean
> );

Another option is to use unnest() to turn the array into a recordset,
which you can then use SQL on. If the array is quite small you might get
away with that. But if you're actually storing images you'll probably be
pretty unhappy with performance, because every time you make ANY change
to that array you'll need to completely re-write the *entire* array to disk.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Chris Winslett 2015-04-08 00:46:21 Re: Asynchronous replication in postgresql
Previous Message Jim Nasby 2015-04-08 00:32:09 Re: Basic Question on Point In Time Recovery