On Mon, 2011-06-20 at 13:43 -0400, Tom Lane wrote:
> The other viable alternative seems to be to require those two properties
> (btree opclass and collation) to be part of a specific range type
> definition. The complaint about that seemed to be that we couldn't
> infer an ANYRANGE type given only
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
Florian Pflug wrote:
On Jun20, 2011, at 20:58 , Tom Lane wrote:
Darren Duncan writes:
I still think that the most elegant solution is for stuff like collation to just
be built-in to the base types that the range is ranging over, meaning we have a
separate text base type for each text collatio
On Jun20, 2011, at 20:58 , Tom Lane wrote:
> Darren Duncan writes:
>> I still think that the most elegant solution is for stuff like collation to
>> just
>> be built-in to the base types that the range is ranging over, meaning we
>> have a
>> separate text base type for each text collation, an
Darren Duncan writes:
> I still think that the most elegant solution is for stuff like collation to
> just
> be built-in to the base types that the range is ranging over, meaning we have
> a
> separate text base type for each text collation, and the text operators are
> polymorphic over all t
Tom Lane wrote:
Florian Pflug writes:
On Jun20, 2011, at 19:16 , Merlin Moncure wrote:
On Mon, Jun 20, 2011 at 11:21 AM, Jeff Davis wrote:
hm, what if there *was( only one range type per base type, but in the
various contexts where specific ordering and collation was important
you could optio
Florian Pflug writes:
> On Jun20, 2011, at 19:16 , Merlin Moncure wrote:
>> On Mon, Jun 20, 2011 at 11:21 AM, Jeff Davis wrote:
>> hm, what if there *was( only one range type per base type, but in the
>> various contexts where specific ordering and collation was important
>> you could optionally
On Jun20, 2011, at 19:16 , Merlin Moncure wrote:
> On Mon, Jun 20, 2011 at 11:21 AM, Jeff Davis wrote:
> hm, what if there *was( only one range type per base type, but in the
> various contexts where specific ordering and collation was important
> you could optionally pass them in? Meaning, the s
On Mon, Jun 20, 2011 at 11:21 AM, Jeff Davis wrote:
> On Mon, 2011-06-20 at 16:01 +0200, Florian Pflug wrote:
>> Hm, I'm starting to wonder if there isn't a way around that. It seems that
>> this restriction comes from the desire to allow functions with the
>> polymorphic signature
>> (ANYELEMEN
On Mon, 2011-06-20 at 16:01 +0200, Florian Pflug wrote:
> Hm, I'm starting to wonder if there isn't a way around that. It seems that
> this restriction comes from the desire to allow functions with the
> polymorphic signature
> (ANYELEMENT, ANYELEMENT) -> ANYRANGE.
>
> The only such function I c
Greg Stark writes:
> On Mon, Jun 20, 2011 at 3:17 PM, Tom Lane wrote:
>> Given the need to deal with multiple collations for collatable types,
>> I'd say it's not so much "unfortunate" as "utterly unworkable". At
>> least unless you give up the notion of binding the collation into the
>> type de
On Mon, Jun 20, 2011 at 3:17 PM, Tom Lane wrote:
> Given the need to deal with multiple collations for collatable types,
> I'd say it's not so much "unfortunate" as "utterly unworkable". At
> least unless you give up the notion of binding the collation into the
> type definition ... which has oth
Robert Haas writes:
> On Mon, Jun 20, 2011 at 2:33 AM, Jeff Davis wrote:
>> 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.
> Boy, that's an unfortunat
On Jun20, 2011, at 15:19 , Robert Haas wrote:
> On Mon, Jun 20, 2011 at 2:33 AM, Jeff Davis wrote:
>> 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,
On Sun, Jun 19, 2011 at 11:33:02PM -0700, Jeff Davis wrote:
> 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 seem
On Mon, Jun 20, 2011 at 2:33 AM, Jeff Davis wrote:
> 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 un
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
On Jun19, 2011, at 20:08 , Jeff Davis wrote:
> On Sun, 2011-06-19 at 12:24 +0200, Martijn van Oosterhout wrote:
>> Collation checking is generally done by the planner. I don't see why
>> the input function should check, the result of an input function is by
>> definition DEFAULT. It's up to the 'in
On Sun, 2011-06-19 at 12:24 +0200, Martijn van Oosterhout wrote:
> Collation checking is generally done by the planner. I don't see why
> the input function should check, the result of an input function is by
> definition DEFAULT. It's up to the 'in' operator to check.
>
> Note that the whole idea
On Sun, Jun 19, 2011 at 11:21:28AM +0200, Florian Pflug wrote:
> > I think rejecting it makes more sense, so a range would not be a
> > collatable type; it just happens to use collations of the subtype
> > internally.
>
> Ah, crap, I put the COLLATE in the wrong place. What I actually
> had in min
On Jun19, 2011, at 00:23 , Jeff Davis wrote:
> On Sat, 2011-06-18 at 22:19 +0200, Florian Pflug wrote:
>> Yes, that seems necessary for consistency. That leaves the question
>> of what to do if someone tries to modify a textrange's collation with
>> a COLLATE clause. For example,
>>
>> For example
On Sat, 2011-06-18 at 22:19 +0200, Florian Pflug wrote:
> Yes, that seems necessary for consistency. That leaves the question
> of what to do if someone tries to modify a textrange's collation with
> a COLLATE clause. For example,
>
> For example, whats the result of
> 'Ä' in '[A,Z']::textrange_
On Jun18, 2011, at 10:10 , Jeff Davis wrote:
> On Fri, 2011-06-10 at 00:26 +0200, Florian Pflug wrote:
> So, I believe that you are proposing to change the concept of a range
> value from "a contiguous set of values" to "a pair of bounds".
Yeah. Mostly though because I figured that'd make defining
On Fri, 2011-06-10 at 00:26 +0200, Florian Pflug wrote:
> Maybe that check should just be removed? If one views the range
> '[L, U)' as a concise way of expressing "L <= x AND x < U" for some
> x, then allowing the case L > U seems quite natural. There won't
> be any such x of course, but the range
On Mon, Jun 13, 2011 at 12:47 AM, Darren Duncan wrote:
>>> If you're referring to the case
>>> (1) Create table with text-range column and collation C1
>>> (2) Add check constraint containing RANGE_EMPTY()
>>> (3) Add data
>>> (4) Alter column to have collation C2, possibly changing
>>> th
Robert Haas wrote:
On Sun, Jun 12, 2011 at 7:53 AM, Florian Pflug wrote:
I think the collation is going to have to be baked into the type
definition, no? You can't just up and change the collation of the
column as you could for a straight text column, if that might cause
the contents of some r
On Sun, Jun 12, 2011 at 7:53 AM, Florian Pflug wrote:
>> I think the collation is going to have to be baked into the type
>> definition, no? You can't just up and change the collation of the
>> column as you could for a straight text column, if that might cause
>> the contents of some rows to be
On Jun12, 2011, at 04:37 , Robert Haas wrote:
> On Thu, Jun 9, 2011 at 6:26 PM, Florian Pflug wrote:
>> On Jun8, 2011, at 17:46 , Jeff Davis wrote:
>>> It looks like the type input function may be a problem, because it
>>> doesn't look like it knows what the collation is yet. In other words,
>>> P
On Thu, Jun 9, 2011 at 6:26 PM, Florian Pflug wrote:
> On Jun8, 2011, at 17:46 , Jeff Davis wrote:
>> It looks like the type input function may be a problem, because it
>> doesn't look like it knows what the collation is yet. In other words,
>> PG_GET_COLLATION() is zero for the type input functio
On Jun8, 2011, at 17:46 , Jeff Davis wrote:
> It looks like the type input function may be a problem, because it
> doesn't look like it knows what the collation is yet. In other words,
> PG_GET_COLLATION() is zero for the type input function.
>
> But I need to do a comparison to find out if the ra
Jeff Davis writes:
> It looks like the type input function may be a problem, because it
> doesn't look like it knows what the collation is yet. In other words,
> PG_GET_COLLATION() is zero for the type input function.
Yeah, we've assumed that I/O functions do not need to know collation.
On Tue, 2011-06-07 at 10:20 -0700, Jeff Davis wrote:
> > BTW, Jeff, have you worked out the implications of collations for
> > textual range types?
>
> Well, "it seems to work" is about as far as I've gotten.
>
> As far as the implications, I'll need to do a little more research and
> thinking. B
Jeff Davis wrote:
On Mon, 2011-06-06 at 14:42 -0700, Darren Duncan wrote:
Can Pg be changed to support "." in operator names as long as they don't just
appear by themselves? What would this break to do so?
Someone else would have to comment on that. My feeling is that it might
create problems
Jeff Davis wrote:
On Tue, 2011-06-07 at 11:15 -0400, Tom Lane wrote:
Merlin Moncure writes:
right. hm -- can you have multiple range type definitions for a
particular type?
In principle, sure, if the type has multiple useful sort orderings.
Right. Additionally, you might want to use differe
Jeff Davis writes:
> On Mon, 2011-06-06 at 14:42 -0700, Darren Duncan wrote:
>> Can Pg be changed to support "." in operator names as long as they don't
>> just
>> appear by themselves? What would this break to do so?
> Someone else would have to comment on that.
DOT_DOT is already a token in
On Mon, 2011-06-06 at 14:42 -0700, Darren Duncan wrote:
> On this note, here's a *big* thing that needs discussion ...
[ refering to the concept of "discrete" versus "continuous" ranges ]
Yes, there has been much discussion on this topic already.
The solution right now is that they both behave l
On Tue, 2011-06-07 at 11:15 -0400, Tom Lane wrote:
> Merlin Moncure writes:
> > right. hm -- can you have multiple range type definitions for a
> > particular type?
>
> In principle, sure, if the type has multiple useful sort orderings.
Right. Additionally, you might want to use different "canon
Merlin Moncure writes:
> On Mon, Jun 6, 2011 at 6:23 PM, Tom Lane wrote:
>> By my count there are only about 20 datatypes in core for which it looks
>> sensible to provide a range type (ie, it's a non-deprecated,
>> non-composite type with a standard default btree opclass). For that
>> many, we
On Mon, Jun 6, 2011 at 6:23 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> I vote for at minimum the type itself and ANYRANGE to be in core.
>> From there you could make it like arrays where the range type is
>> automatically generated for each POD type. I would consider that for
>> sure on bas
Merlin Moncure writes:
> I vote for at minimum the type itself and ANYRANGE to be in core.
> From there you could make it like arrays where the range type is
> automatically generated for each POD type. I would consider that for
> sure on basis of simplicity in user-land unless all the extra type
Jeff Davis wrote:
On Sun, 2011-06-05 at 21:51 -0700, Darren Duncan wrote:
Jeff Davis wrote:
I'd like to take another look at Range Types and whether part of it
should be an extension. Some of these issues relate to extensions in
general, not just range types.
First of all, what are the advanta
Stephen Frost writes:
> I don't like the idea of having a capability which is not utilized
> in core. We should make it so extensions can *also* have access to
> define their own, but we should have the basics covered in core.
Well if another part of core depends on the feature set, then of cour
On Sun, Jun 5, 2011 at 1:59 PM, Jeff Davis wrote:
> In the several talks that I've given, a common question is related to
> "multiranges" (ranges with holes). These get a little complex, and I
> don't have a complete answer. However, multiranges can be approximated
> with ordered arrays of non-ove
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> That means that this is, IMHO, the right approach. Have core support
> that enables user defined RANGE types with indexing and planner support,
> etc, like we have OPERATOR CLASS and FAMILY and all the jazz.
Yes, we do, however..
> And the use
On Mon, Jun 06, 2011 at 12:53:49PM -0400, Robert Haas wrote:
>
> I don't have clear feeling on this question in general, but if we're
> going to break this up into pieces, it's important that they be
> logical pieces. Putting half the feature in core and half into an
> extension just because we c
2011/6/6 Jeff Davis :
> On Mon, 2011-06-06 at 18:28 +0200, Pavel Stehule wrote:
>> we can define a step
>>
>> FOREACH x IN RANGE . BY
>
> That wouldn't need any of the range infrastructure at all -- it would be
> purely syntactic, right?
>
I don't think. For lot of types the specification
On Sun, Jun 5, 2011 at 2:59 PM, Jeff Davis wrote:
> So, where on this spectrum should range types fall? I think the most
> minimalist would be to only support #1 (and the necessary type IO
> functions); and leave all other functions, operators, and opclasses to
> an extension. That has a lot of ap
On Mon, 2011-06-06 at 16:45 +, Christopher Browne wrote:
> How to slice it apart into an appropriate admixture of core and
> extensions is a good question, though it seems pretty likely that
> having an extension for each data type that is to be mixed into a
> range is a reasonable way to go.
On Mon, 2011-06-06 at 18:28 +0200, Pavel Stehule wrote:
> we can define a step
>
> FOREACH x IN RANGE . BY
That wouldn't need any of the range infrastructure at all -- it would be
purely syntactic, right?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hacke
On Sun, Jun 5, 2011 at 6:59 PM, Jeff Davis wrote:
> There might also be some middle ground, where its like the minimalist
> approach, but with a few very basic constructors and accessors. That
> would at least make it easier to test, but then to be actually useful
> (with index support, operators,
On Mon, 2011-06-06 at 14:42 +0200, Dimitri Fontaine wrote:
> I think the way things are going to be organised now is that we will
> have core-blessed extensions: don't mix the mechanism and the policy.
I like that idea.
> > non-issue if we had a good type interface system (that works on
> > poly
2011/6/6 Jeff Davis :
> On Mon, 2011-06-06 at 06:56 +0200, Pavel Stehule wrote:
>> 2011/6/6 Darren Duncan :
>> > Jeff Davis wrote:
>> >>
>> >> I'd like to take another look at Range Types and whether part of it
>> >> should be an extension. Some of these issues relate to extensions in
>> >> general
On Sun, 2011-06-05 at 21:51 -0700, Darren Duncan wrote:
> Jeff Davis wrote:
> > I'd like to take another look at Range Types and whether part of it
> > should be an extension. Some of these issues relate to extensions in
> > general, not just range types.
> >
> > First of all, what are the advanta
On Mon, 2011-06-06 at 06:56 +0200, Pavel Stehule wrote:
> 2011/6/6 Darren Duncan :
> > Jeff Davis wrote:
> >>
> >> I'd like to take another look at Range Types and whether part of it
> >> should be an extension. Some of these issues relate to extensions in
> >> general, not just range types.
> >>
>
Jeff Davis writes:
> I'd like to take another look at Range Types and whether part of it
> should be an extension. Some of these issues relate to extensions in
> general, not just range types.
That's a good question :)
I think the way things are going to be organised now is that we will
have cor
Pavel Stehule wrote:
2011/6/6 Darren Duncan :
Jeff Davis wrote:
I'd like to take another look at Range Types and whether part of it
should be an extension. Some of these issues relate to extensions in
general, not just range types.
First of all, what are the advantages to being in core?
it s
2011/6/6 Darren Duncan :
> Jeff Davis wrote:
>>
>> I'd like to take another look at Range Types and whether part of it
>> should be an extension. Some of these issues relate to extensions in
>> general, not just range types.
>>
>> First of all, what are the advantages to being in core?
it should b
Jeff Davis wrote:
I'd like to take another look at Range Types and whether part of it
should be an extension. Some of these issues relate to extensions in
general, not just range types.
First of all, what are the advantages to being in core?
I believe that ranges aka intervals are widely usefu
I'd like to take another look at Range Types and whether part of it
should be an extension. Some of these issues relate to extensions in
general, not just range types.
First of all, what are the advantages to being in core?
1. ANYRANGE + CREATE TYPE ... AS RANGE
--
59 matches
Mail list logo
