From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Florian Pflug <fgp(at)phlo(dot)org> |
Cc: | Martijn van Oosterhout <kleptog(at)svana(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Darren Duncan <darren(at)darrenduncan(dot)net> |
Subject: | Re: Range Types and extensions |
Date: | 2011-06-20 06:33:02 |
Message-ID: | 1308551582.2597.119.camel@jdavis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, 2011-06-19 at 21:29 +0200, Florian Pflug wrote:
> If I'm not mistaken about this, that would imply that we also cannot
> have two range types with the same base type, the same opclass,
> but different collations. Which seems rather unfortunate... In fact,
> if that's true, maybe restricing range types to the database collation
> would be best...
Yes, we cannot have two range types with the same base type. That is a
consequence of the polymorphic type system, which needs to be able to
determine the range type given the base type.
A workaround is to use domains. That is effective, but awkward. For
instance, given:
CREATE DOMAIN textdomain AS text;
CREATE TYPE textdomainrange AS RANGE (subtype=textdomain);
then:
'[a,z)'::textdomainrange @> 'b'::textdomain
would work, but:
'[a,z)'::textdomainrange @> 'b'
would not, which would be annoying.
I don't see a way around this. It's not a collation problem, but a
general "multiple range types with the same subtype" problem.
I don't think there's much benefit in restricting it to the DB
collation. If someone really needs a different collation (or opclass,
for that matter), it might as well be allowed, even if you have to do
extra type annotations.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Radosław Smogura | 2011-06-20 07:07:19 | Re: Patch - Debug builds without optimization |
Previous Message | Fujii Masao | 2011-06-20 04:53:25 | Re: Latch implementation that wakes on postmaster death on both win32 and Unix |