Re: BUG #9652: inet types don't support min/max

From: Keith Fiske <keith(at)omniti(dot)com>
To: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
Cc: darius(at)dons(dot)net(dot)au, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #9652: inet types don't support min/max
Date: 2014-05-28 17:28:41
Message-ID: CAG1_KcBcavTb2OUoGi1PrAVRs_x4r9afmBK9P0djJnB_3afy8w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Sun, Mar 23, 2014 at 10:42 PM, Haribabu Kommi
<kommi(dot)haribabu(at)gmail(dot)com>wrote:

> On Fri, Mar 21, 2014 at 5:17 PM, <darius(at)dons(dot)net(dot)au> wrote:
> > The following bug has been logged on the website:
> > reclog=> select * from foo;
> > bar
> > ---------
> > 1.2.3.4
> > (1 row)
> >
> > reclog=> select min(bar) from foo;
> > ERROR: function min(inet) does not exist
> > LINE 1: select min(bar) from foo;
> > ^
> > HINT: No function matches the given name and argument types. You might
> need
> > to add explicit type casts.
> >
> > This is surprising to me since the inet type is ordered, hence min/max
> are
> > possible.
>
> In the code, some comparison logic for the inet datatypes already present.
> With those I thought it is easy to support the min and max aggregates also.
> So I modified the code to support the aggregate functions of min and
> max by using
> the already existing inet comparison logic. Is there anything I am missing?
>
> postgres=# create table tbl(f inet);
> CREATE TABLE
> postgres=# insert into tbl values('1.2.3.5');
> INSERT 0 1
> postgres=# insert into tbl values('1.2.3.4');
> INSERT 0 1
> postgres=# select min(f) from tbl;
> min
> ---------
> 1.2.3.4
> (1 row)
>
> postgres=# select max(f) from tbl;
> max
> ---------
> 1.2.3.5
> (1 row)
>
> Patch is attached.
> This is the first time I am touching this area so please let me know
> your suggestions.
>
> Regards,
> Hari Babu
> Fujitsu Australia
>
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
>
>
This is my first time reviewing a patch, so apologies if I've missed
something in the process.

I tried applying your patch to the current git HEAD as of 2014-05-27 and
the portion against pg_aggregate.h fails

postgres $ patch -Np1 -i ../inet_agg.patch
patching file src/backend/utils/adt/network.c
Hunk #1 succeeded at 471 (offset -49 lines).
patching file src/include/catalog/pg_aggregate.h
Hunk #1 FAILED at 140.
Hunk #2 FAILED at 162.
2 out of 2 hunks FAILED -- saving rejects to file
src/include/catalog/pg_aggregate.h.rej
patching file src/include/catalog/pg_proc.h
Hunk #1 succeeded at 2120 (offset 8 lines).
Hunk #2 succeeded at 3163 (offset 47 lines).
Hunk #3 succeeded at 3204 (offset 47 lines).
patching file src/include/utils/builtins.h
Hunk #1 succeeded at 907 (offset 10 lines).

Looks like starting around April 12th some additional changes were made to
the DATA lines in this file that have to be accounted for.

https://github.com/postgres/postgres/commits/master/src/include/catalog/pg_aggregate.h

Don't have the knowledge of how to fix this for the new format, but thought
I'd at least try to apply the patch and see if it works.

--
Keith Fiske
Database Administrator
OmniTI Computer Consulting, Inc.
http://www.keithf4.com

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2014-05-28 19:01:32 Re: pl/pgsql incorrect syntax checking on select .... into ... ?
Previous Message Artiom Makarov 2014-05-28 12:04:32 pl/pgsql incorrect syntax checking on select .... into ... ?

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2014-05-28 17:52:06 Re: pg_stat directory and pg_stat_statements
Previous Message Tom Lane 2014-05-28 16:29:28 Re: Re: popen and pclose redefinitions causing many warning in Windows build