Re: function defined (or not), more worries on version 10->14 upgrade

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Rob Sargent <robjsargent(at)gmail(dot)com>
Cc: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: function defined (or not), more worries on version 10->14 upgrade
Date: 2022-04-15 22:36:16
Message-ID: CAKFQuwYq56qhtrSFWXSzOu_a7ih0Om8uBsYjCNHSc-3Uo6VnAA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, Apr 15, 2022 at 3:02 PM Rob Sargent <robjsargent(at)gmail(dot)com> wrote:

> On 4/15/22 15:52, David G. Johnston wrote:
>
>
>
> On Fri, Apr 15, 2022 at 2:30 PM Rob Sargent <robjsargent(at)gmail(dot)com> wrote:
>
>> On 4/15/22 15:18, David G. Johnston wrote:
>>
>> On Fri, Apr 15, 2022 at 2:04 PM Rob Sargent <robjsargent(at)gmail(dot)com>
>> wrote:
>>
>>> but have not found a combination of name/args for genome_threshold_mono(text,text,double
>>> precision)
>>>
>>>
>> Per the fine documentation:
>>
>> \df[anptwS+] [ pattern [ arg_pattern ... ] ]
>>
>> So the correct formulation is:
>>
>> \df genome_threshold_mono text text 'double precision'
>>
>> You need to quote the fourth argument to protect the embedded space as a
>> character and not an argument separator.
>>
>> David J.
>>
>> Wow. An old bad habit of using parens, I guess?
>>
>> Do you consider this correct behaviour?
>>
>> barnard=# \df public.genome_threshold_mono text,text
>> List of functions
>> Schema | Name | Result data type |
>> Argument data types | Type
>>
>> --------+-----------------------+------------------+--------------------------------------------------------+------
>> public | genome_threshold_mono | uuid | pbs_name text,
>> genome_name text | func
>> public | genome_threshold_mono | uuid | pbs_name text,
>> genome_name text, conf double precision | func
>> (2 rows)
>>
>>
> I cannot reproduce that on head:
>
> \df test_function text
> List of functions
> Schema | Name | Result data type | Argument data types
> | Type
>
> --------+---------------+------------------+------------------------------+------
> public | test_function | text | text, double precision
> | func
> public | test_function | text | text, text, double precision
> | func
> (2 rows)
>
> Isn't the above example exactly my case? It seems to work as "match at
> least these leading args" which in my mind appends a silent ",*". But
> that's just me.
>

name = pattern AND
arg1 = pattern

Now, if you simply omit the pattern for arg2 a two-arg function with the
correct first argument will still match, no wildcards needed - absence of a
third test is how it works.

I get you want this to behave like a single pattern match:
function_signature ~ some_pattern

But it doesn't.

This way is arguably easier for someone who doesn't know regexes well to
use.

Maybe there is value in implementing something like what you are expecting,
which is a bit closer in spirit to what \sf and \ef do, here: but I
wouldn't wager on it happening.

Do you take it as inconsequential that they both deal with specifics of
> named functions and both make use of that functions argument list and are
> part of the same meta-function world within psql?
>

I find this particular inconsistency to be a reasonable one. I'm not
against improving usability here but also am not going to fight for it
either. Partially because I tend to find doing work in text files under
version control is much better than "\ef". And if I know something exists
in the DB and I want details, doing a name-only search followed by \sf
seems like it would work well enough.

David J.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2022-04-15 22:48:15 Re: function defined (or not), more worries on version 10->14 upgrade
Previous Message Tom Lane 2022-04-15 22:06:55 Re: function defined (or not), more worries on version 10->14 upgrade