Re: function defined (or not), more worries on version 10->14 upgrade - Mailing list pgsql-general
| From | David G. Johnston |
|---|---|
| Subject | Re: function defined (or not), more worries on version 10->14 upgrade |
| Date | |
| Msg-id | CAKFQuwYq56qhtrSFWXSzOu_a7ih0Om8uBsYjCNHSc-3Uo6VnAA@mail.gmail.com Whole thread Raw |
| In response to | Re: function defined (or not), more worries on version 10->14 upgrade (Rob Sargent <robjsargent@gmail.com>) |
| Responses |
Re: function defined (or not), more worries on version 10->14 upgrade
(Tom Lane <tgl@sss.pgh.pa.us>)
|
| List | pgsql-general |
On Fri, Apr 15, 2022 at 3:02 PM Rob Sargent <robjsargent@gmail.com> wrote:
On 4/15/22 15:52, David G. Johnston wrote: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.On Fri, Apr 15, 2022 at 2:30 PM Rob Sargent <robjsargent@gmail.com> wrote:On 4/15/22 15:18, David G. Johnston wrote:Wow. An old bad habit of using parens, I guess?On Fri, Apr 15, 2022 at 2:04 PM Rob Sargent <robjsargent@gmail.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.
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 textList 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)
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.
pgsql-general by date: