Re: PostgreSQL Bug with simple function unexpectedly treating varchar parameter as an array
От | Rumpi Gravenstein |
---|---|
Тема | Re: PostgreSQL Bug with simple function unexpectedly treating varchar parameter as an array |
Дата | |
Msg-id | CAEpg1wALRocK=uDSNyJqdc=vhNGjYFmT3H_TNzihSOMS88WHfg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PostgreSQL Bug with simple function unexpectedly treating varchar parameter as an array (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: PostgreSQL Bug with simple function unexpectedly treating varchar parameter as an array
|
Список | pgsql-general |
<snip>
Now I'm wondering about stray entries in pg_cast. Also,
do you have any extensions loaded in that DB that aren't
in your other ones?
do you have any extensions loaded in that DB that aren't
in your other ones?
</snip>
Our databases are deployed with automation tools. They should all be created the same. They all have the same 17 extensions. I've asked a DBA to confirm.
This issue only appears in the function I have listed. A similar function, same contents and parameter but with a different name, works the way I would expect.
On Fri, Jul 25, 2025 at 1:10 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Rumpi Gravenstein <rgravens@gmail.com> writes:
> No ... just one version:
D'oh, actually this would have complained if there was more
than one match, so that theory is wrong:
> xxxx_pub_dev_2_db=# DROP FUNCTION if exists _sa_setup_role;
> DROP FUNCTION
Now I'm wondering about stray entries in pg_cast. Also,
do you have any extensions loaded in that DB that aren't
in your other ones?
regards, tom lane
Rumpi Gravenstein
В списке pgsql-general по дате отправления: