From: | Keith Fiske <keith(at)omniti(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, "Daniel O'Connor" <darius(at)dons(dot)net(dot)au>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] BUG #9652: inet types don't support min/max |
Date: | 2014-06-03 19:46:45 |
Message-ID: | CAG1_KcATQQ7nUt2T555qO2EndpEDx-TN5LmXLCoTduipbX_9dQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On Tue, Jun 3, 2014 at 10:48 AM, Andres Freund <andres(at)2ndquadrant(dot)com>
wrote:
> On 2014-06-03 10:37:53 -0400, Tom Lane wrote:
> > Andres Freund <andres(at)2ndquadrant(dot)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
>
Andres's changes on June 3rd to
https://github.com/postgres/postgres/commits/master/src/test/regress/expected/create_function_3.out
are causing patch v2 to fail for that regression test file.
postgres $ patch -p1 -i ../inet_agg_v2.patch
patching file src/backend/utils/adt/network.c
patching file src/include/catalog/pg_aggregate.h
patching file src/include/catalog/pg_proc.h
patching file src/include/utils/builtins.h
patching file src/test/regress/expected/create_function_3.out
Hunk #1 FAILED at 153.
1 out of 1 hunk FAILED -- saving rejects to file
src/test/regress/expected/create_function_3.out.rej
patching file src/test/regress/expected/inet.out
patching file src/test/regress/sql/inet.sql
Otherwise it applies without any issues to the latest HEAD. I built and
started a new instance, and I was able to test at least the basic min/max
functionality
keith=# create table test_inet (id serial, ipaddress inet);
CREATE TABLE
Time: 25.546 ms
keith=# insert into test_inet (ipaddress) values ('192.168.1.1');
INSERT 0 1
Time: 3.143 ms
keith=# insert into test_inet (ipaddress) values ('192.168.1.2');
INSERT 0 1
Time: 2.932 ms
keith=# insert into test_inet (ipaddress) values ('127.0.0.1');
INSERT 0 1
Time: 1.786 ms
keith=# select min(ipaddress) from test_inet;
min
-----------
127.0.0.1
(1 row)
Time: 3.371 ms
keith=# select max(ipaddress) from test_inet;
max
-------------
192.168.1.2
(1 row)
Time: 1.104 ms
--
Keith Fiske
Database Administrator
OmniTI Computer Consulting, Inc.
http://www.keithf4.com
From | Date | Subject | |
---|---|---|---|
Next Message | Haribabu Kommi | 2014-06-04 00:37:48 | Re: [BUGS] BUG #9652: inet types don't support min/max |
Previous Message | Andres Freund | 2014-06-03 14:48:24 | Re: [HACKERS] BUG #9652: inet types don't support min/max |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-06-03 19:48:09 | Re: Hide 'Execution time' in EXPLAIN (COSTS OFF) |
Previous Message | Robert Haas | 2014-06-03 19:40:27 | Re: Hide 'Execution time' in EXPLAIN (COSTS OFF) |