Re: [BUGS] BUG #9652: inet types don't support min/max - Mailing list pgsql-hackers
| From | Keith Fiske |
|---|---|
| Subject | Re: [BUGS] BUG #9652: inet types don't support min/max |
| Date | |
| Msg-id | CAG1_KcATQQ7nUt2T555qO2EndpEDx-TN5LmXLCoTduipbX_9dQ@mail.gmail.com Whole thread Raw |
| In response to | Re: [BUGS] BUG #9652: inet types don't support min/max (Andres Freund <andres@2ndquadrant.com>) |
| Responses |
Re: [BUGS] BUG #9652: inet types don't support min/max
|
| List | pgsql-hackers |
On Tue, Jun 3, 2014 at 10:48 AM, Andres Freund <andres@2ndquadrant.com> wrote:
On 2014-06-03 10:37:53 -0400, Tom Lane wrote:Well, I personally wouldn't have noticed that the OP's patch marked the
> 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.
new functions as leakproof without that test. At least not while looking
at the patch. pg_proc.h is just too hard to read.I don't object to moving it there.
> 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.)
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
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
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
pgsql-hackers by date: