| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Darren Duncan <darren(at)darrenduncan(dot)net> |
| Cc: | Florian Pflug <fgp(at)phlo(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Range Types and extensions |
| Date: | 2011-06-21 08:29:58 |
| Message-ID: | 1308644998.2443.11.camel@jdavis |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 2011-06-20 at 12:54 -0700, Darren Duncan wrote:
> That DOMAIN-based solution ostensibly sounds like a good one then, under the
> circumstances.
It's not bad from a theoretical standpoint, but it does require some
extra type annotation, which is not really the "SQL way".
> What I *don't* want to see is for things like ranges to have
> their own collations and the like.
I'm not 100% sure what you mean here. If you mean that you don't want
range types to pay attention to COLLATE clauses, etc., then I agree. I
would also agree if you mean that range values should not carry the
collation with them.
However, it looks like we might try to make the opclass/collation pair a
property of the range type definition. That seems nice, because it
allows us to keep the nice properties of ranges as well as the type
inference and polymorphism for everything except the constructors.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2011-06-21 08:31:11 | Re: Range Types and extensions |
| Previous Message | Michael Meskes | 2011-06-21 08:20:17 | Re: Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault. |