public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: Rumpi Gravenstein <[email protected]>
Cc: PostgreSQL <[email protected]>
Subject: Re: PostgreSQL Bug with simple function unexpectedly treating varchar parameter as an array
Date: Fri, 25 Jul 2025 13:50:19 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAEpg1wALRocK=uDSNyJqdc=vhNGjYFmT3H_TNzihSOMS88WHfg@mail.gmail.com>
References: <CAEpg1wBxp=25isxj6yt2cf97KtvbwxvJfrJ9qYF8UQxGSBJ93Q@mail.gmail.com>
<[email protected]>
<CAEpg1wCDL+iYbG7ByjHcgfvJy7m3m-rDp-xKiYovvxeKTbG7iQ@mail.gmail.com>
<[email protected]>
<CAEpg1wALRocK=uDSNyJqdc=vhNGjYFmT3H_TNzihSOMS88WHfg@mail.gmail.com>
Rumpi Gravenstein <[email protected]> writes:
> 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.
Well, there's got to be *something* different about that database.
> 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.
That sure seems like evidence in favor of the similarly-named-function
idea. But I don't see how the DROP FUNCTION wouldn't have failed if
there were two, nor why we wouldn't see it in \df.
regards, tom lane
view thread (7+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: PostgreSQL Bug with simple function unexpectedly treating varchar parameter as an array
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox