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
Reply to list also.
Ccing list.
On 2/1/24 09:11, Johnathan Tiamoh wrote:
No. I have done any of this in the present cluster, I'm facing this issue.
Do you have some sort of replication or backup system running on this
cluster?
--
Adrian Klaver
adrian.kla...@aklaver.com
On 2/1/24 06:10, Johnathan Tiamoh wrote:
I haven't had difficulties in this cluster recently.
However I upgraded it from version 9.5 to 14.10 about 3 weeks ago.
Have you being doing any of the things that got you in trouble in this
thread:
https://www.postgresql.org/message-id/CACoPQdbEo
I haven't had difficulties in this cluster recently.
However I upgraded it from version 9.5 to 14.10 about 3 weeks ago.
On Thu, Feb 1, 2024 at 9:06 AM Jehan-Guillaume de Rorthais
wrote:
> On Thu, 1 Feb 2024 08:28:45 -0500
> Johnathan Tiamoh wrote:
>
> > Thank you Laurenz!
> >
> > Is there
On Thu, 1 Feb 2024 08:28:45 -0500
Johnathan Tiamoh wrote:
> Thank you Laurenz!
>
> Is there a way of preventing this from happening ?
This could either come from a hardware issue, or easily from your own actions
or procedures.
Did you have some difficulties with your instance lately? exception
Thank you Laurenz!
Is there a way of preventing this from happening ?
On Thu, Feb 1, 2024 at 2:36 AM Laurenz Albe
wrote:
> On Thu, 2024-02-01 at 00:48 -0500, Johnathan Tiamoh wrote:
> > I am having the following issue below. Please, I need help to fix it.
> >
> > ERROR: could not access stat
On Thu, 2024-02-01 at 00:48 -0500, Johnathan Tiamoh wrote:
> I am having the following issue below. Please, I need help to fix it.
>
> ERROR: could not access status of transaction 756525298
> Could not open file "pg_xact/02C8": No such file or directory.
That is data corruption, and you shoul
Hello,
I am having the following issue below. Please, I need help to fix it.
[image: User]
*ERROR: could not access status of transaction 756525298*
*Could not open file "pg_xact/02C8": No such file or directory.*
Thank You
Johnathan T
## m...@ft-c.de (m...@ft-c.de):
> /usr/local/bin/postgres -V
> ld-elf.so.1: Shared object "libicui18n.so.70" not found, required by
> "postgres"
You screwd up your upgrades: that postgres binary was built against
ICU 70, but as hou have shown you have ICU 71 installed:
> find / -name "*libicui*"
On Fri, 2022-07-08 at 12:47 +0200, m...@ft-c.de wrote:
> there is a postgresql bug
An error need not be a bug.
> /usr/local/bin/postgres -V
> ld-elf.so.1: Shared object "libicui18n.so.70" not found, required by
> "postgres"
>
> Installed Version:
> p
Hallo,
there is a postgresql bug
/usr/local/bin/postgres -V
ld-elf.so.1: Shared object "libicui18n.so.70" not found, required by
"postgres"
Installed Version:
postgresql14-server-14.1
find / -name "*libicui*"
/usr/local/lib/libicuio.a
/usr/local/lib/libicui18n.so
On Wed, 23 Mar 2022 at 04:03, PALAYRET Jacques
wrote:
> For example, in Oracle it is not possible to have a SELECT statement without
> a FROM clause (using DUAL table), so maybe " ambiguous " columns are not
> handled in the same way.
But if your original complaint, the column was not ambiguous
;PostgreSQL mailing lists"
Envoyé: Mardi 22 Mars 2022 14:04:32
Objet: Re: PostgreSQL : bug (ou not) in CTE Common Table Expressions or
Subqueries in the FROM Clause
On Tuesday, March 22, 2022, PALAYRET Jacques < [
mailto:jacques.palay...@meteo.fr | jacques.palay...@meteo.fr ] > wr
On Tuesday, March 22, 2022, PALAYRET Jacques
wrote:
>
> According to me, there is only one condition in the main statement (SELECT
> w.id, w.name, w.elev FROM weather_stations ...)
> and it is : elev > 151 (correlation ou not correlation).
> In others words : for each line of table weather_statio
nks again.
Regards
De: "Torsten Förtsch"
À: "PALAYRET Jacques"
Cc: "PostgreSQL mailing lists"
Envoyé: Mardi 22 Mars 2022 11:16:19
Objet: Re: PostgreSQL : bug (ou not) in CTE Common Table Expressions or
Subqueries in the FROM Clause
This is what happens:
WITH ele
On Tuesday, March 22, 2022, Torsten Förtsch wrote:
>
>
> Note the use of aliases, w and x. You are using a correlated subquery.
>
Yep. There is an FAQ entry if you’d like a bit more exposition.
https://wiki.postgresql.org/wiki/FAQ#Why_doesn.27t_PostgreSQL_report_a_column_not_found_error_when_us
t; SELECT id, name, elev FROM weather_stations WHERE elev > (
> SELECT elev FROM (SELECT * FROM weather_stations WHERE id=31069001)
> elev_Tlse_Blagnac
> )
> AND id BETWEEN 3100 and 3199
> ;
> id| name | elev
> --+--+--
> 31006001 | ALBIAC AGGLOMERATION | 289
> 31010001 | LUCHON-ANTIGNAC | 599
> (2 lignes)
>
>
> Is that a PostgreSQL bug or not, statement 1 or statement 3 (yes according
> to me) ?
>
Not a bug, just following the SQL standard as far as I remember.
--
Guillaume.
http://www.dalibo.com
289
> 31010001 | LUCHON-ANTIGNAC | 599
> 50195001 | GATHEMO | 330
> (3 lignes)
>
> # OK (of course) :
> = Statement 5 : =
> SELECT id, name, elev FROM weather_stations WHERE elev > (
> SELECT elev FROM (SELECT * FROM weather_stations WHERE id=31069001)
&
weather_stations WHERE id=31069001)
elev_Tlse_Blagnac
)
AND id BETWEEN 3100 and 3199
;
id | name | elev
--+--+--
31006001 | ALBIAC AGGLOMERATION | 289
31010001 | LUCHON-ANTIGNAC | 599
(2 lignes)
Is that a PostgreSQL bug or not, statement 1 or statemen
40 matches
Mail list logo
