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

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: function defined (or not), more worries on version 10->14 upgrade
Дата
Msg-id CAKFQuwYq56qhtrSFWXSzOu_a7ih0Om8uBsYjCNHSc-3Uo6VnAA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: function defined (or not), more worries on version 10->14 upgrade  (Rob Sargent <robjsargent@gmail.com>)
Ответы Re: function defined (or not), more worries on version 10->14 upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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:


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:
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.

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.

В списке pgsql-general по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: function defined (or not), more worries on version 10->14 upgrade
Следующее
От: Tom Lane
Дата:
Сообщение: Re: function defined (or not), more worries on version 10->14 upgrade