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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
