On Thu, 2009-11-26 at 16:31 -0500, Robert Haas wrote:
> On Thu, Nov 26, 2009 at 4:33 AM, Jeff Davis <pg...@j-davis.com> wrote:
> > Thanks, I applied it. The only significant thing I changed was that I
> > did not inline the "index_elem" because it made it fairly hard to read.
> > Instead, I renamed it "exclude_elem" to make it a little more
> > meaningful, which I assume may have been your motivation for inlining
> > it.
>
> No, it was really just that I didn't see any point in defining a token
> that was only used in one place. It seems like it just represents a
> jumble of tokens without any real connection between them, so I didn't
> really see why we should break out that piece as opposed to anything
> else.
"table_constraint" and "column_constraint" are only used one place. I
found it convenient to do so because, in the common case, exclude_elem
is just a column name. So the user clearly sees:
exclude_elem WITH operator
and the pairing isn't obscured by a bunch of optional stuff.
> I'm (still) not an expert on this topic, but here's one more thought:
> maybe we should try to set this up so that it works in any situation
> in which an opclass itself would work. IOW, if you manage to define
> an opclass, you should probably be able to define an
> operator-exclusion constraint against it, rather than having some
> opclasses work and others arbitrarily fail.
That's what I was aiming for, but it's theoretically possible for that
case to require casts. I will do a little more investigation and write a
test case. If it looks reasonable, I'll refactor a little and just do
it. It is a pretty obscure case (seeing as I have yet to observe it,
including all contrib modules plus postgis), but I might as well do it
right as long as it's reasonable to do. If it gets even messier to
implement, maybe I'll reconsider.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
