Re: Singleton range constructors versus functional coercion notation
От | Robert Haas |
---|---|
Тема | Re: Singleton range constructors versus functional coercion notation |
Дата | |
Msg-id | CA+TgmobOC7Re2_XM5Y+OVM=gzk_9LRpKNGFt6RF=TJhGhkk6OA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Singleton range constructors versus functional coercion notation (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Singleton range constructors versus functional
coercion notation
(Jeff Davis <pgsql@j-davis.com>)
|
Список | pgsql-hackers |
On Mon, Nov 21, 2011 at 9:55 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Nov 20, 2011, at 10:24 PM, Jeff Davis <pgsql@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 canmake 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
В списке pgsql-hackers по дате отправления: