Re: Adding argument names to aggregate functions - Mailing list pgsql-hackers

From Dagfinn Ilmari Mannsåker
Subject Re: Adding argument names to aggregate functions
Date
Msg-id 87sfcxv61h.fsf@wibble.ilmari.org
Whole thread Raw
In response to Re: Adding argument names to aggregate functions  (Jim Jones <jim.jones@uni-muenster.de>)
Responses Re: Adding argument names to aggregate functions  (Jim Jones <jim.jones@uni-muenster.de>)
List pgsql-hackers
Jim Jones <jim.jones@uni-muenster.de> writes:

> On 18.04.23 10:58, I wrote:
>> On 14.04.23 12:03, Dagfinn Ilmari Mannsåker wrote:
>>> Thanks for the heads-up, here's a rebased patch. I've also formatted
>>> the lines to match what reformat_dat_file.pl wants.  It also wanted to
>>> reformat a bunch of other entries, but I left those alone.
>>>
>>> - ilmari
>>
>> The patch applies cleanly now and \df shows the argument names:
>>
>> postgres=# \df string_agg
>>                                 List of functions
>>    Schema   |    Name    | Result data type |     Argument data
>> types      | Type
>> ------------+------------+------------------+------------------------------+------ 
>>  pg_catalog | string_agg | bytea            | value bytea, delimiter bytea | agg
>>  pg_catalog | string_agg | text             | value text, delimiter text   | agg
>> (2 rows)
>>
>> postgres=# \df json_object_agg
>>                                 List of functions
>>    Schema   |      Name       | Result data type |  Argument data
>> types   | Type
>> ------------+-----------------+------------------+------------------------+------ 
>>  pg_catalog | json_object_agg | json             | key "any", value "any" | agg
>> (1 row)
>>
>>
>> I'm wondering if there are some sort of guidelines that dictate when
>> to name an argument or not. It would be nice to have one for future 
>> reference.

I seemed to recall a patch to add arugment names to a bunch of functions
in the past, thinking that might have some guidance, but can't for the
life of me find it now.

>> I will mark the CF entry as "Read for Committer" and let the
>> committers decide if it's best to first create a guideline for that or 
>> not.
>>
>> Best, Jim
>>
> I just saw that the patch is failing[1] on "macOS - Ventura -
> Meson". Not sure if it is related to this patch though ..
>
> [1]
> https://api.cirrus-ci.com/v1/artifact/task/5881376021413888/meson_log/build/meson-logs/meson-log.txt

Link to the actual job:

https://cirrus-ci.com/task/5881376021413888

The failure was:

[09:54:38.727] 216/262 postgresql:recovery / recovery/031_recovery_conflict ERROR 198.73s exit status 60

Looking at its log:


https://api.cirrus-ci.com/v1/artifact/task/5881376021413888/testrun/build/testrun/recovery/031_recovery_conflict/log/regress_log_031_recovery_conflict

we see:

timed out waiting for match: (?^:User was holding a relation lock for too long) at
/Users/admin/pgsql/src/test/recovery/t/031_recovery_conflict.plline 311.
 

That looks indeed completely unrelated to this patch.

- ilmari



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Incremental sort for access method with ordered scan support (amcanorderbyop)
Next
From: Jim Jones
Date:
Subject: Re: Adding argument names to aggregate functions