On Wed, Jul 6, 2011 at 1:19 AM, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2011-07-05 at 13:06 -0400, Robert Haas wrote:
On Tue, Jul 5, 2011 at 12:54 PM, Jeff Davis pg...@j-davis.com wrote:
It would be something like: range_co(1,8)::int8range
(just so we're comparing apples to apples)
On Wed, 2011-07-06 at 09:10 -0400, Robert Haas wrote:
There's some slight ugliness around the NULL/infinity business, but I
think that I could be convinced. I'd like to avoid confusion between
NULL and infinity if possible.
I was thinking that if you passed 'i' for one of the bounds, it
On Wed, Jul 6, 2011 at 12:22 PM, Jeff Davis pg...@j-davis.com wrote:
To get into some more details: how exactly would this constructor be
generated on the fly? Clearly we want only one underlying C function
that accepts something like:
range_internal(lower, upper, flags, Oid rangetype)
So
On Wed, 2011-07-06 at 12:51 -0400, Robert Haas wrote:
On Wed, Jul 6, 2011 at 12:22 PM, Jeff Davis pg...@j-davis.com wrote:
To get into some more details: how exactly would this constructor be
generated on the fly? Clearly we want only one underlying C function
that accepts something like:
Jeff Davis pg...@j-davis.com writes:
On Wed, 2011-07-06 at 12:51 -0400, Robert Haas wrote:
On Wed, Jul 6, 2011 at 12:22 PM, Jeff Davis pg...@j-davis.com wrote:
To get into some more details: how exactly would this constructor be
generated on the fly? Clearly we want only one underlying C
On Wed, 2011-07-06 at 15:14 -0400, Tom Lane wrote:
I ran into problems with that before... I think with the I/O functions.
I don't think that's a problem here, but I thought I'd ask.
I think it'd probably be all right to do that. The places where you
might find shortcuts being taken are
On Fri, Jul 1, 2011 at 2:09 AM, Jeff Davis pg...@j-davis.com wrote:
On Thu, 2011-06-30 at 12:28 +0200, Florian Pflug wrote:
Well, arrays are containers, and we need two values to construct a range,
What about empty ranges? What about infinite ranges?
It seems quite a bit more awkward to
On Tue, 2011-07-05 at 10:06 -0400, Robert Haas wrote:
But if it's actually better, we should do it. If an intermediate type
seems to be problematic, or if people think it's strange to require
casting, then I think this is reasonable.
I don't understand how the bespoke syntax avoids the
On Tue, Jul 5, 2011 at 11:11 AM, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2011-07-05 at 10:06 -0400, Robert Haas wrote:
But if it's actually better, we should do it. If an intermediate type
seems to be problematic, or if people think it's strange to require
casting, then I think this is
On Jul5, 2011, at 17:11 , Jeff Davis wrote:
I'm OK with the intermediate type, but Florian seems skeptical of that
idea.
I'm starting to get used to it, though ;-) I do now believe that it can
be made safe against accidental miss-use, it seem that I was overly
anxious there.
What I still don't
On Tue, Jul 5, 2011 at 10:26 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jul 5, 2011 at 11:11 AM, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2011-07-05 at 10:06 -0400, Robert Haas wrote:
But if it's actually better, we should do it. If an intermediate type
seems to be problematic,
On Tue, Jul 5, 2011 at 12:23 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Tue, Jul 5, 2011 at 10:26 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jul 5, 2011 at 11:11 AM, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2011-07-05 at 10:06 -0400, Robert Haas wrote:
But if it's actually
On Tue, 2011-07-05 at 11:26 -0400, Robert Haas wrote:
How about the idea of creating a family of four constructor functions
for each new range type? The functions would be named after the range
type, with _cc, _co, _oc, and _oo appended. So, then, instead
of writing:
On Tue, Jul 5, 2011 at 12:54 PM, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2011-07-05 at 11:26 -0400, Robert Haas wrote:
How about the idea of creating a family of four constructor functions
for each new range type? The functions would be named after the range
type, with _cc, _co, _oc, and
On Tue, 2011-07-05 at 13:06 -0400, Robert Haas wrote:
On Tue, Jul 5, 2011 at 12:54 PM, Jeff Davis pg...@j-davis.com wrote:
It would be something like: range_co(1,8)::int8range
(just so we're comparing apples to apples)
The intermediate type proposal doesn't require that we move the c
On Thu, 2011-06-30 at 09:59 -0700, David E. Wheeler wrote:
On Jun 30, 2011, at 9:34 AM, Jeff Davis wrote:
Then how do you get a text range that doesn't correspond to the
LC_COLLATE setting?
You cast it.
My original solution was something like this, except involving domains.
With a
On Thu, 2011-06-30 at 12:28 +0200, Florian Pflug wrote:
Well, arrays are containers, and we need two values to construct a range,
What about empty ranges? What about infinite ranges?
It seems quite a bit more awkward to shoehorn ranges into an array than
to use a real type (even if it's
On Jun29, 2011, at 23:44 , Peter Eisentraut wrote:
On ons, 2011-06-29 at 10:15 -0700, David E. Wheeler wrote:
On Jun 29, 2011, at 10:13 AM, Florian Pflug wrote:
Because there might be more than one range type for a
base type. Say there are two range types over text, one
with collation 'de_DE'
On tor, 2011-06-30 at 08:45 +0200, Florian Pflug wrote:
I don't think it will - as it stands, there isn't a single collatable
type RANGE but instead one *distinct* type per combination of base
type, btree opclass and collation. The reasons for that were discussed
at length - the basic argument
On Jun30, 2011, at 09:05 , Peter Eisentraut wrote:
On tor, 2011-06-30 at 08:45 +0200, Florian Pflug wrote:
I don't think it will - as it stands, there isn't a single collatable
type RANGE but instead one *distinct* type per combination of base
type, btree opclass and collation. The reasons for
On Jun29, 2011, at 17:41 , Jeff Davis wrote:
Is it? That's actually too bad, since I kinda like it. But anyway,
if that's a concern it could also be
range_bounds(ARRAY[1,2]::int8range, '(]')
What type would the result of that be? What value?
ARRAY[1,2]::int8range would return an int8range
On Thu, 2011-06-30 at 09:11 +0200, Florian Pflug wrote:
How would the system catalogs be initialized under that theory: surely
you're not going to seed (nr. of types) * (nr. of collations) * (nr. of
opclasses) range types in initdb?
There's CREATE RANGE.
Right. In that respect, it's more
On Wed, 2011-06-29 at 10:15 -0700, David E. Wheeler wrote:
On Jun 29, 2011, at 10:13 AM, Florian Pflug wrote:
Because there might be more than one range type for a
base type. Say there are two range types over text, one
with collation 'de_DE' and one with collation 'en_US'.
What would
On Wed, 2011-06-29 at 12:34 -0400, Robert Haas wrote:
But now that I'm thinking about this a little more, I'm worried about this
case:
CREATE TABLE foo AS RANGE('something'::funkytype, 'somethingelse'::funktype);
DROP TYPE funkytype;
It seems to me that the first statement had better
On Jun 30, 2011, at 9:29 AM, Jeff Davis wrote:
Right. In that respect, it's more like a record type: many possible
record types exist, but you only define the ones you want.
Well, okay. How is this same problem handled for RECORD types, then?
By default, no range types would exists I
On Jun 30, 2011, at 9:34 AM, Jeff Davis wrote:
Then how do you get a text range that doesn't correspond to the
LC_COLLATE setting?
You cast it.
Does that mean you couldn't dump/reload from a
system with one collation and get the same values in a system with a
different collation? That
On Thu, 2011-06-30 at 09:58 -0700, David E. Wheeler wrote:
On Jun 30, 2011, at 9:29 AM, Jeff Davis wrote:
Right. In that respect, it's more like a record type: many possible
record types exist, but you only define the ones you want.
Well, okay. How is this same problem handled for RECORD
On Jun29, 2011, at 05:02 , Jeff Davis wrote:
On Tue, 2011-06-28 at 22:20 +0200, Florian Pflug wrote:
I believe if we go that route we should make RANGEINPUT a full-blown
type, having pair of bound semantics. Adding a lobotomized version
just for the sake of range input feels a bit like a
On Tue, Jun 28, 2011 at 11:02 PM, Jeff Davis pg...@j-davis.com wrote:
It's still not out of the question, but I thought that the intermediate
type would be a less-intrusive alternative (and Robert seemed concerned
about how intrusive it was).
I'm no great fan of our existing type system, and
On Wed, 2011-06-29 at 13:35 +0200, Florian Pflug wrote:
What I'm concerned about is how elegantly we'd be able to tie up all
the loose ends. What'd be the result of
select range(1,2)
for example? Or
create table (r rangeinput)
for that matter.
I think we'd want to forbid both of
On Wed, 2011-06-29 at 08:52 -0400, Robert Haas wrote:
On Tue, Jun 28, 2011 at 11:02 PM, Jeff Davis pg...@j-davis.com wrote:
It's still not out of the question, but I thought that the intermediate
type would be a less-intrusive alternative (and Robert seemed concerned
about how intrusive it
On Wed, Jun 29, 2011 at 11:41 AM, Jeff Davis pg...@j-davis.com wrote:
Robert didn't really seem to like the idea of throwing an error though
-- Robert, can you expand on your reasoning here?
I guess I don't have any terribly well-thought out reasoning - maybe
it's fine. It just seems strange
On Jun 28, 2011, at 8:02 PM, Jeff Davis wrote:
I think David Wheeler was trying to make a similar point, but I'm still
not convinced.
It's not a pair, because it can be made up of 0, 1, or 2 scalar values
(unless you count infinity as one of those values, in which case 0 or
2). And without
On Jun 29, 2011, at 8:41 AM, Jeff Davis wrote:
We could make it a pseudo-type and make the IO functions generate
exceptions. That should prevent most mistakes and effectively hide it
from the user (sure, they could probably use it somewhere if they really
want to, but I wouldn't be worried
On Jun29, 2011, at 18:34 , Robert Haas wrote:
It also seems a bit strange to me that we're contemplating a system
where users are always going to have to cast the return type.
Generally, casts are annoying and we want to minimize the need for
them. I'm not sure what the alternative is,
On Jun29, 2011, at 19:05 , David E. Wheeler wrote:
I'm still not clear, though, on why the return type of range()
should not be related to the types of its arguments. So
range(1, 5)
Should return intrange, and
range(1::int8, 5::int8)
Should return int8range, and
On Jun 29, 2011, at 10:13 AM, Florian Pflug wrote:
Because there might be more than one range type for a
base type. Say there are two range types over text, one
with collation 'de_DE' and one with collation 'en_US'.
What would the type of
range('foo', 'f')
be?
The one that corresponds
On ons, 2011-06-29 at 10:15 -0700, David E. Wheeler wrote:
On Jun 29, 2011, at 10:13 AM, Florian Pflug wrote:
Because there might be more than one range type for a
base type. Say there are two range types over text, one
with collation 'de_DE' and one with collation 'en_US'.
What would
On Mon, Jun 27, 2011 at 11:42 PM, Jeff Davis pg...@j-davis.com wrote:
So, in effect, RANGEINPUT is a special type used only for range
constructors. If someone tried to output it, it would throw an
exception, and we'd even have enough information at that point to print
a nice error message with
On Jun 27, 2011, at 8:42 PM, Jeff Davis wrote:
Do we think that this is a good way forward? The only thing I can think
of that's undesirable is that it's not normal to be required to cast the
result of a function, and might be slightly difficult to explain in the
documentation in a
On Tue, 2011-06-28 at 10:58 -0400, Robert Haas wrote:
On Mon, Jun 27, 2011 at 11:42 PM, Jeff Davis pg...@j-davis.com wrote:
So, in effect, RANGEINPUT is a special type used only for range
constructors. If someone tried to output it, it would throw an
exception, and we'd even have enough
On Tue, 2011-06-28 at 09:30 -0700, David E. Wheeler wrote:
On Jun 27, 2011, at 8:42 PM, Jeff Davis wrote:
Do we think that this is a good way forward? The only thing I can think
of that's undesirable is that it's not normal to be required to cast the
result of a function, and might be
On Tue, Jun 28, 2011 at 12:58 PM, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2011-06-28 at 10:58 -0400, Robert Haas wrote:
On Mon, Jun 27, 2011 at 11:42 PM, Jeff Davis pg...@j-davis.com wrote:
So, in effect, RANGEINPUT is a special type used only for range
constructors. If someone tried to
On Jun28, 2011, at 05:42 , Jeff Davis wrote:
On Mon, 2011-06-27 at 14:50 -0400, Robert Haas wrote:
Couldn't we also do neither of these things? I mean, presumably
'[1,10]'::int8range had better work.
I think that if we combine this idea with Florian's PAIR suggestion
here:
On Tue, 2011-06-28 at 22:20 +0200, Florian Pflug wrote:
Hm, so RANGEINPUT would actually be what was previously discussed as
the range as a pair of bounds definition, as opposed to the
range as a set of values definition. So essentially we'd add a
second concept of what a range is to work
Jeff Davis wrote:
On Sun, 2011-06-26 at 00:57 -0700, Darren Duncan wrote:
I believe that the best general solution here is for every ordered base type to
just have a single total order, which is always used with that type in any
generic order-sensitive operation, including any ranges defined
On Jun27, 2011, at 02:48 , Jeff Davis wrote:
On Mon, 2011-06-27 at 00:56 +0200, Florian Pflug wrote:
Well, there actually *is* some precedence for that kind of top-down
(form a syntactic perspective) type inference. We *enforce* the cast
in
array[]::arraytype
and actually for a very
On Mon, 2011-06-27 at 12:16 +0200, Florian Pflug wrote:
I wouldn't take it that far. What I had in mind was to *only* support
the case where the cast directly follows the function call, i.e. the case
f(...)::type
OK, so instead of writing:
On Sun, 2011-06-26 at 22:29 -0700, Darren Duncan wrote:
Tom Lane wrote:
Darren Duncan dar...@darrenduncan.net writes:
I believe that the best general solution here is for every ordered base
type to
just have a single total order, which is always used with that type in any
generic
Jeff Davis wrote:
On Sun, 2011-06-26 at 22:29 -0700, Darren Duncan wrote:
Tom Lane wrote:
Darren Duncan dar...@darrenduncan.net writes:
I believe that the best general solution here is for every ordered base type to
just have a single total order, which is always used with that type in any
On Sat, Jun 25, 2011 at 6:29 PM, Jeff Davis pg...@j-davis.com wrote:
Different ranges over the same subtype make sense when using different
total orders for the subtype. This is most apparent with text collation,
but makes sense (at least mathematically, if not practically) for any
subtype.
On Mon, 2011-06-27 at 14:50 -0400, Robert Haas wrote:
Couldn't we also do neither of these things? I mean, presumably
'[1,10]'::int8range had better work.
I think that if we combine this idea with Florian's PAIR suggestion
here:
To eludicate my earlier comments on this subject ...
I believe that the best general solution here is for every ordered base type to
just have a single total order, which is always used with that type in any
generic order-sensitive operation, including any ranges defined over it, or any
ORDER
Darren Duncan dar...@darrenduncan.net writes:
I believe that the best general solution here is for every ordered base type
to
just have a single total order, which is always used with that type in any
generic order-sensitive operation, including any ranges defined over it, or
any
ORDER
On Sun, 2011-06-26 at 00:57 -0700, Darren Duncan wrote:
I believe that the best general solution here is for every ordered base type
to
just have a single total order, which is always used with that type in any
generic order-sensitive operation, including any ranges defined over it, or
On Jun26, 2011, at 00:29 , Jeff Davis wrote:
declare the return type of a function, and then use the declared type to
infer the argument types. That would be nice because you would just have
to do:
range(1,10)::int8range
However, that's kind of backwards from how our type inference system
On Mon, 2011-06-27 at 00:56 +0200, Florian Pflug wrote:
Well, there actually *is* some precedence for that kind of top-down
(form a syntactic perspective) type inference. We *enforce* the cast
in
array[]::arraytype
and actually for a very similar reason - without the case, there's no
way
Tom Lane wrote:
Darren Duncan dar...@darrenduncan.net writes:
I believe that the best general solution here is for every ordered base type to
just have a single total order, which is always used with that type in any
generic order-sensitive operation, including any ranges defined over it, or
Different ranges over the same subtype make sense when using different
total orders for the subtype. This is most apparent with text collation,
but makes sense (at least mathematically, if not practically) for any
subtype.
For instance:
[a, Z)
is a valid range in en_US, but not in C, so it makes
59 matches
Mail list logo
