On 8/6/25 14:39, Rumpi Gravenstein wrote:
That having a table and function with similar names causes this problem
is a bug.
Actually it is that a type and function have the same name. The
connection is the table as that where the type gets it's name. Further
complicated by you doing _type_nam
On Wed, Aug 6, 2025 at 2:39 PM Rumpi Gravenstein wrote:
> That having a table and function with similar names causes this problem is
> a bug.
>
>
Arguably. But it seems likely it's one we are not going to fix.
David J.
"David G. Johnston" writes:
> On Wednesday, August 6, 2025, Rumpi Gravenstein wrote:
>> Here's a reproducible test case that causes the problem in different
>> schemas. The issue appears to be related to creating a table and a
>> function that has the same name as the table with a prepended unde
That having a table and function with similar names causes this problem is
a bug.
Going forward I'll be sure to avoid the problem.
On Wed, Aug 6, 2025 at 5:35 PM David G. Johnston
wrote:
> On Wednesday, August 6, 2025, Rumpi Gravenstein
> wrote:
>
>> Here's a reproducible test case that causes
On Wednesday, August 6, 2025, Rumpi Gravenstein wrote:
> Here's a reproducible test case that causes the problem in different
> schemas. The issue appears to be related to creating a table and a
> function that has the same name as the table with a prepended underscore.
>
Don’t do that. Naming
Here's a reproducible test case that causes the problem in different
schemas. The issue appears to be related to creating a table and a
function that has the same name as the table with a prepended underscore.
rumpi_test -- table name
_rumpi_test -- function name
Here's the test case;
SELECT v
On Wednesday, August 6, 2025, Rumpi Gravenstein 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
> -+--+--
On 8/6/25 1:17 PM, Rumpi Gravenstein wrote:
Just coming back to this. Don't know how to interpret this:
xxx_pub_dev_2_db=# select proname, pronamespace, oid from pg_proc where
proname like '%sa_setup%';
proname | pronamespace | oid
+--+-
_sa_s
Just coming back to this. Don't know how to interpret this:
xxx_pub_dev_2_db=# select proname, pronamespace, oid from pg_proc where
proname like '%sa_setup%';
proname | pronamespace | oid
+--+-
_sa_setup_role | 7038406 | 7869125
(1 row)
xxx_pub_
Puzzling.
I'd do:
pg_dump --schema-only xxx_pub_dev_2_db | grep -i -A5 _sa_setup_role
Note the -i. That _might_ be important.
On Wed, Aug 6, 2025 at 4:18 PM Rumpi Gravenstein wrote:
> Just coming back to this. Don't know how to interpret this:
>
> xxx_pub_dev_2_db=# select proname, pronamesp
Laurenz Albe writes:
> On Fri, 2025-07-25 at 14:10 -0400, Tom Lane wrote:
>> So ... any chance you have a data type named _sa_setup_role?
> ... it could also be a type "sa_setup_role", and "_sa_setup_role"
> is interpreted as the corresponding array type:
Oh, of course --- that's a good deal mor
On Fri, 2025-07-25 at 14:10 -0400, Tom Lane wrote:
> After looking at the code I remembered that the parser might be taking
> this as a type coercion request. With that idea, I can duplicate the
> observed behavior like so:
>
> regression=# select _sa_setup_role('af_repo_app');
> INFO: af_repo_a
I wrote:
> Well, there's got to be *something* different about that database.
After looking at the code I remembered that the parser might be taking
this as a type coercion request. With that idea, I can duplicate the
observed behavior like so:
regression=# select _sa_setup_role('af_repo_app');
Rumpi Gravenstein 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 functio
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?
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
Rumpi Gravenstein writes:
> No ... just one version:
D'oh, actually this would have complained if there was more
than one match, so that theory is wrong:
> _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
There is really only one function with this name. A rerun of my test
script with the suggested change:
_pub_dev_2_db=# SELECT version();
version
---
On 7/25/25 09:59, Rumpi Gravenstein wrote:
No ... just one version:
_pub_dev_2_db=# \df _sa_setup_role
Do:
\df *._sa_setup_role
--
Rumpi Gravenstein
--
Adrian Klaver
adrian.kla...@aklaver.com
No ... just one version:
_pub_dev_2_db=# SHOW server_version;
server_version
16.9
(1 row)
_pub_dev_2_db=# DROP FUNCTION if exists _sa_setup_role;
DROP FUNCTION
_pub_dev_2_db=# CREATE OR REPLACE FUNCTION _sa_setup_role(
p_role_to_be_granted varchar)
_pub_dev_2_d
Rumpi Gravenstein writes:
> I've been confound by the following behavior that I see in one of our
> PostgreSQL 16 instances. In this case I am running this script from psql.
I'd bet there is another function named _sa_setup_role() that takes
some kind of array, and the parser is resolving the am
On 7/25/25 09:36, Rumpi Gravenstein wrote:
PostgreSQL Experts,
I've been confound by the following behavior that I see in one of our
PostgreSQL 16 instances. In this case I am running this script from psql.
-
PostgreSQL Experts,
I've been confound by the following behavior that I see in one of our
PostgreSQL 16 instances. In this case I am running this script from psql.
-
_pub_dev_2_db=# SELECT
22 matches
Mail list logo
