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*
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 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 Mon, Jun 20, 2011 at 2:33 AM, Jeff Davis pg...@j-davis.com 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
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 seems
On Jun20, 2011, at 15:19 , Robert Haas wrote:
On Mon, Jun 20, 2011 at 2:33 AM, Jeff Davis pg...@j-davis.com 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
Robert Haas robertmh...@gmail.com writes:
On Mon, Jun 20, 2011 at 2:33 AM, Jeff Davis pg...@j-davis.com 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
On Mon, Jun 20, 2011 at 3:17 PM, Tom Lane t...@sss.pgh.pa.us 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 ...
Greg Stark st...@mit.edu writes:
On Mon, Jun 20, 2011 at 3:17 PM, Tom Lane t...@sss.pgh.pa.us 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
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 can
On Mon, Jun 20, 2011 at 11:21 AM, Jeff Davis pg...@j-davis.com 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
On Jun20, 2011, at 19:16 , Merlin Moncure wrote:
On Mon, Jun 20, 2011 at 11:21 AM, Jeff Davis pg...@j-davis.com 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?
Florian Pflug f...@phlo.org writes:
On Jun20, 2011, at 19:16 , Merlin Moncure wrote:
On Mon, Jun 20, 2011 at 11:21 AM, Jeff Davis pg...@j-davis.com 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
Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
On Jun20, 2011, at 19:16 , Merlin Moncure wrote:
On Mon, Jun 20, 2011 at 11:21 AM, Jeff Davis pg...@j-davis.com wrote:
hm, what if there *was( only one range type per base type, but in the
various contexts where specific ordering and
Darren Duncan dar...@darrenduncan.net 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
On Jun20, 2011, at 20:58 , Tom Lane wrote:
Darren Duncan dar...@darrenduncan.net 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
Florian Pflug wrote:
On Jun20, 2011, at 20:58 , Tom Lane wrote:
Darren Duncan dar...@darrenduncan.net 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
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, whats
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 mind was
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 of
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 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 is
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 their
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
On Jun12, 2011, at 04:37 , Robert Haas wrote:
On Thu, Jun 9, 2011 at 6:26 PM, Florian Pflug f...@phlo.org 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,
On Sun, Jun 12, 2011 at 7:53 AM, Florian Pflug f...@phlo.org 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
Robert Haas wrote:
On Sun, Jun 12, 2011 at 7:53 AM, Florian Pflug f...@phlo.org 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
On Mon, Jun 13, 2011 at 12:47 AM, Darren Duncan dar...@darrenduncan.net 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
On Thu, Jun 9, 2011 at 6:26 PM, Florian Pflug f...@phlo.org 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
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 range
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. But I don't
Jeff Davis pg...@j-davis.com 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
On Mon, Jun 6, 2011 at 6:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com 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
Merlin Moncure mmonc...@gmail.com writes:
On Mon, Jun 6, 2011 at 6:23 PM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, 2011-06-07 at 11:15 -0400, Tom Lane wrote:
Merlin Moncure mmonc...@gmail.com 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
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 like
Jeff Davis pg...@j-davis.com 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
Jeff Davis wrote:
On Tue, 2011-06-07 at 11:15 -0400, Tom Lane wrote:
Merlin Moncure mmonc...@gmail.com 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
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 pg...@j-davis.com 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
On Mon, 2011-06-06 at 06:56 +0200, Pavel Stehule wrote:
2011/6/6 Darren Duncan dar...@darrenduncan.net:
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
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 advantages to
2011/6/6 Jeff Davis pg...@j-davis.com:
On Mon, 2011-06-06 at 06:56 +0200, Pavel Stehule wrote:
2011/6/6 Darren Duncan dar...@darrenduncan.net:
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
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
On Sun, Jun 5, 2011 at 6:59 PM, Jeff Davis pg...@j-davis.com 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
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
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 Sun, Jun 5, 2011 at 2:59 PM, Jeff Davis pg...@j-davis.com 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
2011/6/6 Jeff Davis pg...@j-davis.com:
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
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 can
* 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 useful
On Sun, Jun 5, 2011 at 1:59 PM, Jeff Davis pg...@j-davis.com 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
Stephen Frost sfr...@snowman.net 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
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
Merlin Moncure mmonc...@gmail.com 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
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
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
2011/6/6 Darren Duncan dar...@darrenduncan.net:
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?
Pavel Stehule wrote:
2011/6/6 Darren Duncan dar...@darrenduncan.net:
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
59 matches
Mail list logo
