Re: general purpose array_sort

On Wed, Oct 30, 2024 at 10:41 PM Junwang Zhao <zhjwpku(at)gmail(dot)com> wrote:
>
> On Wed, Oct 30, 2024 at 10:17 PM Junwang Zhao <zhjwpku(at)gmail(dot)com> wrote:
> >
> > Hi,
> >
> > On Wed, Oct 30, 2024 at 9:29 PM Aleksander Alekseev
> > <aleksander(at)timescale(dot)com> wrote:
> > >
> > > Hi,
> > >
> > > Thanks for the updated patch set.
> > >
> > > > > > +Datum
> > > > > > +array_sort_order(PG_FUNCTION_ARGS)
> > > > > > +{
> > > > > > + return array_sort(fcinfo);
> > > > > > +}
> > > > > > +
> > > > > > +Datum
> > > > > > +array_sort_order_nulls_first(PG_FUNCTION_ARGS)
> > > > > > +{
> > > > > > + return array_sort(fcinfo);
> > > > > > +}
> > > > >
> > > > > Any reason not to specify array_sort in pg_proc.dat?
> > > >
> > > > It is specified in 0001 (see oid => '8810').
> > >
> > > What I meant was that I don't think these wrapper functions are
> > > needed. I think you can just do:
> > >
> > > ```
> > > +{ oid => '8811', descr => 'sort array',
> > > + proname => 'array_sort', prorettype => 'anyarray',
> > > + proargtypes => 'anyarray bool', prosrc => 'array_sort'}, <--
> > > array_sort is used directly in `prosrc`
> > > ```
> > >
> > > ... unless I'm missing something.
> >
> > There is a opr sanity check for this[1], if we remove these wrapper functions,
> > regression test will fail with:
> >
> > - oid | proname | oid | proname
> > ------+---------+-----+---------
> > -(0 rows)
> > + oid | proname | oid | proname
> > +------+------------+------+------------
> > + 8811 | array_sort | 8812 | array_sort
> > + 8810 | array_sort | 8811 | array_sort
> > + 8810 | array_sort | 8812 | array_sort
> > +(3 rows)
> >
> >
> > [1]:
> >
> > -- Considering only built-in procs (prolang = 12), look for multiple uses
> > -- of the same internal function (ie, matching prosrc fields). It's OK to
> > -- have several entries with different pronames for the same internal function,
> > -- but conflicts in the number of arguments and other critical items should
> > -- be complained of. (We don't check data types here; see next query.)
> > -- Note: ignore aggregate functions here, since they all point to the same
> > -- dummy built-in function.
> >
> > SELECT p1.oid, p1.proname, p2.oid, p2.proname
> > FROM pg_proc AS p1, pg_proc AS p2
> > WHERE p1.oid < p2.oid AND
> > p1.prosrc = p2.prosrc AND
> > p1.prolang = 12 AND p2.prolang = 12 AND
> > (p1.prokind != 'a' OR p2.prokind != 'a') AND
> > (p1.prolang != p2.prolang OR
> > p1.prokind != p2.prokind OR
> > p1.prosecdef != p2.prosecdef OR
> > p1.proleakproof != p2.proleakproof OR
> > p1.proisstrict != p2.proisstrict OR
> > p1.proretset != p2.proretset OR
> > p1.provolatile != p2.provolatile OR
> > p1.pronargs != p2.pronargs);
> >
> > >
> > > --
> > > Best regards,
> > > Aleksander Alekseev
> >
> >
> >
> > --
> > Regards
> > Junwang Zhao
>
> CFbot failed with doc build, v10 fixed that.
>
> --
> Regards
> Junwang Zhao

Rebase needed due to array_reverse committed, PFA v11.

--
Regards
Junwang Zhao