Re: WIP: extensible enums

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Robert Haas <robertmhaas(at)gmail(dot)com>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP: extensible enums
Date: 2010-10-24 21:20:55
Message-ID: 4CC4A337.9080300@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/24/2010 03:28 PM, Tom Lane wrote:
> This patch isn't committable as-is because I haven't made enum_first,
> enum_last, enum_range follow these coding rules: they need to stop
> using the syscache and instead use an indexscan on
> pg_enum_typid_sortorder_index to locate the relevant rows. That should
> be just a small fix though, and it seems likely to be a net win for
> performance anyway. There are a couple of other loose ends too, in
> particular I still think we need to prevent ALTER TYPE ADD inside a
> transaction block because of the risk of finding undefined enum OIDs
> in indexes. Anybody really unhappy with this approach? If not, I'll
> finish this up and commit it.

I'll look at it tonight. At first glance it looks OK.

(BTW, this would be a good case for publishing your development branch
somewhere (e.g. git.postgresql.org) That way I could import it and
easily do a diff between your patch and mine, in about three simple
commands. There are other ways of getting at it, and I'll go and do
that, but we should start to look at using the nice facilities git
provides.)

cheers

andrew

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2010-10-24 21:24:07 Re: WIP: extensible enums
Previous Message Andrew Dunstan 2010-10-24 21:09:18 Re: WIP: extensible enums