On Mon, Jul 2, 2012 at 11:25 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> On Mon, Jul 2, 2012 at 6:59 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> Um, doesn't that require nonrectangular arrays?
>
>> Doh. You're right: I keep forgetting that arrays have to be rectangular.
>
>> Any suggestions on a sensible way to represent this?
>
> Are there likely to be enough entries that storage efficiency actually
> matters? If not, we could use a 2xN array of {key,allowed_value} pairs,
> that is
>
> {{thingy,item1},{thingy,item2},{otherthingy,foo},{otherthingy,bar}}
>
> Or perhaps push these out into a separate table, along the lines
> of
> oid key allowed_value
> and use an oidvector to list the selected values in a trigger entry?
It seems likely that there will fairly commonly be many allowed values
per key. However, the universe of legal keys will be quite small,
probably a total of 2-4. So maybe the best representation is to have
an a separate column for each key and store the array of legal values
in it. That's more or less what Dimitri already has in his latest
patch, except that after looking it over I'm inclined to think that
we'd be better off storing the keys as text and translating to
internal ID numbers when we read and cache the table, rather than
storing the ID numbers in the table. That will make the catalog
contents easier to read, and more importantly will mean that a change
to the internal ID numbers need not be initdb-forcing.
Thoughts?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
