Re: [HACKERS] Singleton range constructors versus functional coercion notation
On Mon, Nov 21, 2011 at 9:55 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Nov 20, 2011, at 10:24 PM, Jeff Davis pg...@j-davis.com wrote: Well, if there were a good shorter notation, then probably so. But it doesn't look like we have a good idea, so I'm fine with dropping it. We should also keep in mind that people who use range types can and likely will define their own convenience functions. If people use singletons, or open ranges, or closed ranges, or one-hour timestamp ranges frequently, they can make their own notational shorthand with a 3-line CREATE FUNCTION statement. We don't need to have it all in core. But if you believe that, what syntax do you think people are likely to try if they want a singleton range constructor? Leaving the user to discover the problem and try to invent a workaround is not better than doing it ourselves ... Wait, do I hear the great Tom Lane arguing for putting more than the minimal amount of stuff in core? :-) I honestly don't know what function names people will pick, and I don't care. Someone might like singleton(x), which would be impractical as a built-in because there could be more than one range type over the same base type, but if the user defines the function they can pick what's convenient for them. If they use singletons exceedingly frequently they might even want something really short, like just(x) or s(x). Or they might say daterange1(x), along the lines you suggested earlier. The point is that by not defining more than necessary in core, we give the user the flexibility to do what they want. In cases where that amounts to handing them a loaded gun with the safety off, we shouldn't do it, but that doesn't seem to be the case here. It doesn't take a lot of programming acumen to write a function that passes two copies of its single argument to a built-in. The only mistake anyone's likely to make is forgetting to declare it non-VOLATILE. But the real point is that I don't think we should assume that singleton ranges are unique in being things for which people will want shortcuts. We talked about having a behavior-changing GUC to control whether the bounds are [) or [] or () or (], but we didn't do it, because behavior-changing GUCs are a bad idea. But I fully expect that people who make heavy use of range types will (and we should encourage them to) define convenience functions with names of their own choosing that pass the bounds that are useful to them. If isn't the very model of a use-case for inline-able SQL functions, I'm not sure what is. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Singleton range constructors versus functional coercion notation
On Tue, 2011-11-22 at 09:07 -0500, Robert Haas wrote: I honestly don't know what function names people will pick, and I don't care. Someone might like singleton(x), which would be impractical as a built-in because there could be more than one range type over the same base type, but if the user defines the function they can pick what's convenient for them. If they use singletons exceedingly frequently they might even want something really short, like just(x) or s(x). Or they might say daterange1(x), along the lines you suggested earlier. For that matter, they might pick daterange(x), as I picked earlier, and run into the same problems. It's a little strange that we allow people to define functions with one argument and the same name as a type if such functions are confusing. This isn't intended as an argument in either direction, just an observation. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Singleton range constructors versus functional coercion notation
Jeff Davis pg...@j-davis.com writes:
It's a little strange that we allow people to define functions with one
argument and the same name as a type if such functions are confusing.
As long as your mental model is that such a function is a cast,
everything is fine. The trouble with the range constructors is that
they aren't really casts, as shown by the fact that when you read
textrange('foo')
you expect 'foo' to be text and not textrange.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Singleton range constructors versus functional coercion notation
On Nov 20, 2011, at 10:24 PM, Jeff Davis pg...@j-davis.com wrote: On Sat, 2011-11-19 at 15:57 -0500, Tom Lane wrote: I'm hesitant to remove them because the alternative is significantly more verbose: numrange(1.0, 1.0, '[]'); Right. The question is, does the case occur in practice often enough to justify a shorter notation? I'm not sure. Well, if there were a good shorter notation, then probably so. But it doesn't look like we have a good idea, so I'm fine with dropping it. We should also keep in mind that people who use range types can and likely will define their own convenience functions. If people use singletons, or open ranges, or closed ranges, or one-hour timestamp ranges frequently, they can make their own notational shorthand with a 3-line CREATE FUNCTION statement. We don't need to have it all in core. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Singleton range constructors versus functional coercion notation
Robert Haas robertmh...@gmail.com writes: On Nov 20, 2011, at 10:24 PM, Jeff Davis pg...@j-davis.com wrote: Well, if there were a good shorter notation, then probably so. But it doesn't look like we have a good idea, so I'm fine with dropping it. We should also keep in mind that people who use range types can and likely will define their own convenience functions. If people use singletons, or open ranges, or closed ranges, or one-hour timestamp ranges frequently, they can make their own notational shorthand with a 3-line CREATE FUNCTION statement. We don't need to have it all in core. But if you believe that, what syntax do you think people are likely to try if they want a singleton range constructor? Leaving the user to discover the problem and try to invent a workaround is not better than doing it ourselves ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Singleton range constructors versus functional coercion notation
On 21 November 2011 14:55, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Nov 20, 2011, at 10:24 PM, Jeff Davis pg...@j-davis.com wrote:
Well, if there were a good shorter notation, then probably so. But it
doesn't look like we have a good idea, so I'm fine with dropping it.
We should also keep in mind that people who use range types can and likely
will define their own convenience functions. If people use singletons, or
open ranges, or closed ranges, or one-hour timestamp ranges frequently, they
can make their own notational shorthand with a 3-line CREATE FUNCTION
statement. We don't need to have it all in core.
But if you believe that, what syntax do you think people are likely to
try if they want a singleton range constructor? Leaving the user to
discover the problem and try to invent a workaround is not better than
doing it ourselves ...
In the field of mathematics, a standard shorthand notation for the
degenerate interval [x,x] is {x} - the singleton set - so that's one
possibility.
Dean
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Singleton range constructors versus functional coercion notation
On Sat, 2011-11-19 at 15:57 -0500, Tom Lane wrote: I'm hesitant to remove them because the alternative is significantly more verbose: numrange(1.0, 1.0, '[]'); Right. The question is, does the case occur in practice often enough to justify a shorter notation? I'm not sure. Well, if there were a good shorter notation, then probably so. But it doesn't look like we have a good idea, so I'm fine with dropping it. One thing I've been thinking for a bit is that for discrete ranges, I find the '[)' canonical form to be surprising/confusing. If we were to fix range_adjacent along the lines suggested by Florian, would it be practical to go over to '[]' as the canonical form? One good thing about that approach is that canonicalization wouldn't have to involve generating values that might overflow. I think we had that discussion before, and Florian brought up some good points (both then and in a reply now). Also, Robert wasn't convinced that '[]' is necessarily better for discrete ranges: http://archives.postgresql.org/pgsql-hackers/2011-10/msg00598.php Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Singleton range constructors versus functional coercion notation
On Sat, 2011-11-19 at 12:27 -0500, Tom Lane wrote: The singleton range constructors don't work terribly well. ... I don't immediately see a solution that's better than dropping the single-argument range constructors. We could change the name, I suppose, but that seems awkward. I'm hesitant to remove them because the alternative is significantly more verbose: numrange(1.0, 1.0, '[]'); But I don't have any particularly good ideas to save them, either. Regarding the zero-argument (empty) constructors, I'd be fine removing them. They don't seem to cause problems, but the utility is also very minor. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Singleton range constructors versus functional coercion notation
2011/11/19 Jeff Davis pg...@j-davis.com: On Sat, 2011-11-19 at 12:27 -0500, Tom Lane wrote: The singleton range constructors don't work terribly well. ... I don't immediately see a solution that's better than dropping the single-argument range constructors. We could change the name, I suppose, but that seems awkward. I'm hesitant to remove them because the alternative is significantly more verbose: numrange(1.0, 1.0, '[]'); one parameter range should be confusing. Single parameter range constructors is useless Regards Pavel But I don't have any particularly good ideas to save them, either. Regarding the zero-argument (empty) constructors, I'd be fine removing them. They don't seem to cause problems, but the utility is also very minor. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Singleton range constructors versus functional coercion notation
Jeff Davis pg...@j-davis.com writes: On Sat, 2011-11-19 at 12:27 -0500, Tom Lane wrote: I don't immediately see a solution that's better than dropping the single-argument range constructors. We could change the name, I suppose, but that seems awkward. Yeah, something like int4range_1(42) would work, but it seems rather ugly. I'm hesitant to remove them because the alternative is significantly more verbose: numrange(1.0, 1.0, '[]'); Right. The question is, does the case occur in practice often enough to justify a shorter notation? I'm not sure. One thing I've been thinking for a bit is that for discrete ranges, I find the '[)' canonical form to be surprising/confusing. If we were to fix range_adjacent along the lines suggested by Florian, would it be practical to go over to '[]' as the canonical form? One good thing about that approach is that canonicalization wouldn't have to involve generating values that might overflow. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Singleton range constructors versus functional coercion notation
On Nov19, 2011, at 21:57 , Tom Lane wrote: One thing I've been thinking for a bit is that for discrete ranges, I find the '[)' canonical form to be surprising/confusing. If we were to fix range_adjacent along the lines suggested by Florian, would it be practical to go over to '[]' as the canonical form? One good thing about that approach is that canonicalization wouldn't have to involve generating values that might overflow. I have argued against that in the past, mostly because 1) It's better to be consistent 2) While it seems intuitive for integer ranges to use [] and float ranges to use [), things are far less clear once you take other base types into account. For example, we'd end up making ranges over DATE use canonicalize to [], but ranges over TIMESTAMP to [). Which, at least IMHO, is quite far from intuitive. And if we start fixing these issues by making exception from the discrete - [], continuous - [) rule, we'll end up with essentially arbitrary behaviour pretty quickly. At which point (1) kicks it ;-) And then there also ranges over NUMERIC, which can be both discrete and continuous, depending on the typmod. Which I think is a good reason in itself to make as little behaviour as possible depend on the continuity or non-continuity of range types. best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
