Re: [BUGS] BUG #9652: inet types don't support min/max
От | Andres Freund |
---|---|
Тема | Re: [BUGS] BUG #9652: inet types don't support min/max |
Дата | |
Msg-id | 20140603144824.GE1220@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #9652: inet types don't support min/max (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [BUGS] BUG #9652: inet types don't support min/max
|
Список | pgsql-hackers |
On 2014-06-03 10:37:53 -0400, Tom Lane wrote: > Andres Freund <andres@2ndquadrant.com> writes: > > On 2014-06-03 10:24:46 -0400, Tom Lane wrote: > >> Personally, I would wonder why the regression tests contain such a query > >> in the first place. It seems like nothing but a major maintenance PITA. > > > I haven't added it, but it seems appropriate in that specific case. The > > number of leakproof functions should be fairly small and every addition > > should be carefully reviewed... I am e.g. not sure that it's a good idea > > to declare network_smaller/greater as leakproof - but it's hard to catch > > that on the basic of pg_proc.h alone. > > Meh. I agree that new leakproof functions should be carefully reviewed, > but I have precisely zero faith that this regression test will contribute > to that. Well, I personally wouldn't have noticed that the OP's patch marked the new functions as leakproof without that test. At least not while looking at the patch. pg_proc.h is just too hard to read. > It hasn't even got a comment saying why changes here should > receive any scrutiny; moreover, it's not in a file where changes would be > likely to excite suspicion. (Probably it should be in opr_sanity, if > we're going to have such a thing at all.) I don't object to moving it there. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: