PostgreSQL Bug with simple function unexpectedly treating varchar parameter as an array

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Rumpi Gravenstein <rgravens(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, PostgreSQL <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: PostgreSQL Bug with simple function unexpectedly treating varchar parameter as an array
Date: 2025-08-06 20:43:22
Message-ID: CAKFQuwZJJQz=Ap_S7taL1iJwS6tT0AvrVGThpxWMgQk9ZLSy2w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wednesday, August 6, 2025, Rumpi Gravenstein <rgravens(at)gmail(dot)com> wrote:

>
> xxx_pub_dev_2_db=# drop FUNCTION if exists _sa_setup_role;
> DROP FUNCTION
> xxx_pub_dev_2_db=# select proname, pronamespace, oid from pg_proc where
> proname like '%sa_setup%';
> proname | pronamespace | oid
> ---------+--------------+-----
> (0 rows)
>
> xxx_pub_dev_2_db=# select _sa_setup_role('af_repo_app');
> ERROR: malformed array literal: "af_repo_app"
> LINE 1: select _sa_setup_role('af_repo_app');
> ^
> DETAIL: Array value must start with "{" or dimension information.
> xxx_pub_dev_2_db=#
>

Yeah, we’ve already pretty much decided this function has nothing to do
with it. Go look at pg_type per the last example demonstrating the same
error without the involvement of any user-defined function.

David J.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Laurenz Albe 2025-08-06 20:52:52 Re: analyze-in-stages post upgrade questions
Previous Message Adrian Klaver 2025-08-06 20:43:06 Re: PostgreSQL Bug with simple function unexpectedly treating varchar parameter as an array