Re: [PATCH] pg_sleep(interval)
От | Robert Haas |
---|---|
Тема | Re: [PATCH] pg_sleep(interval) |
Дата | |
Msg-id | CA+Tgmobb5wke-8cFk2oNyTV4YMm561ca9kfRxa7y_o2MnhAEoA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] pg_sleep(interval) (Josh Berkus <josh@agliodbs.com>) |
Список | pgsql-hackers |
On Thu, Oct 17, 2013 at 1:10 PM, Josh Berkus <josh@agliodbs.com> wrote: > On 10/17/2013 10:01 AM, Robert Haas wrote: >> But if you're asking my opinion, I think doing it on the function >> level is a whole lot better and easier to get right. A flag like the >> one I mentioned here can be set for one particular function with the >> absolute certainty that behavior will not change for any function with >> some other name. That type of surety is pretty much impossible to get >> with casts. > > The other argument for doing it at the function level is that we could > then expose it to users, who could use it to manage their own overloaded > functions. We would NOT want to encourage users to mess with cast > precedence, because it would be impossible for them to achieve their > desired result that way. > > On the other hand, prioritization at the function level likely wouldn't > help us with operators at all, because there the cast has to be chosen > before we choose a function. So if we pursued the function route, then > we'd eventually want to add a "preferred" flag for operators too. Which > would be a lot more trouble, because it would affect the planner, but at > least that would be a seperate step. Actually the operator resolution code is very much parallel to the function resolution code. I am quite sure in Advanced Server we only needed to add proisweak to handle both cases; unless I'm quite mistaken, we did not add oprisweak. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: