public inbox for [email protected]
help / color / mirror / Atom feed[Patch] Block ALTER TABLE RENAME COLUMN when column is used by property graph
6+ messages / 3 participants
[nested] [flat]
* [Patch] Block ALTER TABLE RENAME COLUMN when column is used by property graph
@ 2026-04-23 06:53 SATYANARAYANA NARLAPURAM <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: SATYANARAYANA NARLAPURAM @ 2026-04-23 06:53 UTC (permalink / raw)
To: PostgreSQL Hackers <[email protected]>; Ashutosh Bapat <[email protected]>
Hi hackers,
When a table column is referenced by a property graph, the property
name stored in pg_propgraph_property.pgpname would become stale after
a column rename. This caused GRAPH_TABLE queries to fail with the new
column name ("property does not exist") while the old (dead) name
continued to work. pg_get_propgraphdef() would also emit confusing
output like "new_col AS old_col".
Fix by checking pg_depend in renameatt_internal() for
PropgraphLabelPropertyRelationId entries that reference the column
being renamed. If any exist, raise an error directing the user to
drop the property graph first.
Thanks,
Satya
Attachments:
[application/octet-stream] 0001-Block-ALTER-TABLE-RENAME-COLUMN-when-column-is-used-.patch (6.3K, 3-0001-Block-ALTER-TABLE-RENAME-COLUMN-when-column-is-used-.patch)
download | inline diff:
From f0640472cfabc960d1c07a6f596cccaaddbb9d41 Mon Sep 17 00:00:00 2001
From: satyanarayana narlapuram <[email protected]>
Date: Tue, 21 Apr 2026 05:15:43 +0000
Subject: [PATCH] Block ALTER TABLE RENAME COLUMN when column is used by
property graph
When a table column is referenced by a property graph, the property
name stored in pg_propgraph_property.pgpname would become stale after
a column rename. This caused GRAPH_TABLE queries to fail with the new
column name ("property does not exist") while the old (dead) name
continued to work. pg_get_propgraphdef() would also emit confusing
output like "new_col AS old_col".
Fix by checking pg_depend in renameatt_internal() for
PropgraphLabelPropertyRelationId entries that reference the column
being renamed. If any exist, raise an error directing the user to
drop the property graph first.
This is consistent with how DROP COLUMN already blocks when a property
graph depends on the column.
---
src/backend/commands/tablecmds.c | 53 +++++++++++++++++++
.../expected/create_property_graph.out | 17 ++++++
.../regress/sql/create_property_graph.sql | 16 ++++++
3 files changed, 86 insertions(+)
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index eec09ba1..78b6e467 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -48,6 +48,7 @@
#include "catalog/pg_opclass.h"
#include "catalog/pg_policy.h"
#include "catalog/pg_proc.h"
+#include "catalog/pg_propgraph_label_property.h"
#include "catalog/pg_publication_rel.h"
#include "catalog/pg_rewrite.h"
#include "catalog/pg_statistic_ext.h"
@@ -3997,6 +3998,58 @@ renameatt_internal(Oid myrelid,
/* new name should not already exist */
(void) check_for_column_name_collision(targetrelation, newattname, false);
+ /*
+ * Disallow renaming columns that are used by a property graph. The
+ * property graph catalog stores the property name in
+ * pg_propgraph_property.pgpname, which would become stale after a
+ * rename, causing GRAPH_TABLE queries using the new column name to fail
+ * while the old (dead) name would still work.
+ */
+ {
+ Relation depRel;
+ ScanKeyData key[3];
+ SysScanDesc depScan;
+ HeapTuple depTup;
+
+ depRel = table_open(DependRelationId, AccessShareLock);
+
+ ScanKeyInit(&key[0],
+ Anum_pg_depend_refclassid,
+ BTEqualStrategyNumber, F_OIDEQ,
+ ObjectIdGetDatum(RelationRelationId));
+ ScanKeyInit(&key[1],
+ Anum_pg_depend_refobjid,
+ BTEqualStrategyNumber, F_OIDEQ,
+ ObjectIdGetDatum(myrelid));
+ ScanKeyInit(&key[2],
+ Anum_pg_depend_refobjsubid,
+ BTEqualStrategyNumber, F_INT4EQ,
+ Int32GetDatum((int32) attnum));
+
+ depScan = systable_beginscan(depRel, DependReferenceIndexId, true,
+ NULL, 3, key);
+
+ while (HeapTupleIsValid(depTup = systable_getnext(depScan)))
+ {
+ Form_pg_depend depForm = (Form_pg_depend) GETSTRUCT(depTup);
+
+ if (depForm->classid == PropgraphLabelPropertyRelationId)
+ {
+ systable_endscan(depScan);
+ table_close(depRel, AccessShareLock);
+ ereport(ERROR,
+ (errcode(ERRCODE_DEPENDENT_OBJECTS_STILL_EXIST),
+ errmsg("cannot rename column \"%s\" of table \"%s\" because a property graph depends on it",
+ oldattname,
+ RelationGetRelationName(targetrelation)),
+ errhint("Drop the property graph first, then rename the column.")));
+ }
+ }
+
+ systable_endscan(depScan);
+ table_close(depRel, AccessShareLock);
+ }
+
/* apply the update */
namestrcpy(&(attform->attname), newattname);
diff --git a/src/test/regress/expected/create_property_graph.out b/src/test/regress/expected/create_property_graph.out
index bc9a596e..a1d3e6a0 100644
--- a/src/test/regress/expected/create_property_graph.out
+++ b/src/test/regress/expected/create_property_graph.out
@@ -901,6 +901,23 @@ ERROR: cannot add temporary element table to non-temporary property graph
LINE 2: ADD VERTEX TABLES (v2tmp KEY (m));
^
DETAIL: Table "v2tmp" is a temporary table.
+-- ALTER TABLE RENAME COLUMN should be blocked when column is used by
+-- a property graph (the property graph catalog stores property names
+-- that would become stale after the rename)
+CREATE TABLE rename_test (id int PRIMARY KEY, val text);
+CREATE PROPERTY GRAPH g_rename VERTEX TABLES (rename_test KEY (id));
+ALTER TABLE rename_test RENAME COLUMN val TO new_val; -- error
+ERROR: cannot rename column "val" of table "rename_test" because a property graph depends on it
+HINT: Drop the property graph first, then rename the column.
+ALTER TABLE rename_test RENAME COLUMN id TO new_id; -- error (KEY column)
+ERROR: cannot rename column "id" of table "rename_test" because a property graph depends on it
+HINT: Drop the property graph first, then rename the column.
+-- renaming a column not used by the graph should still work
+ALTER TABLE rename_test ADD COLUMN extra int;
+ALTER TABLE rename_test RENAME COLUMN extra TO extra2; -- ok
+ALTER TABLE rename_test DROP COLUMN extra2;
+DROP PROPERTY GRAPH g_rename;
+DROP TABLE rename_test;
-- DROP, ALTER SET SCHEMA, ALTER PROPERTY GRAPH RENAME TO
DROP TABLE g2; -- error: wrong object type
ERROR: "g2" is not a table
diff --git a/src/test/regress/sql/create_property_graph.sql b/src/test/regress/sql/create_property_graph.sql
index 241f93df..03096f5d 100644
--- a/src/test/regress/sql/create_property_graph.sql
+++ b/src/test/regress/sql/create_property_graph.sql
@@ -347,6 +347,22 @@ ALTER PROPERTY GRAPH g1
ADD VERTEX TABLES (v2tmp KEY (m)); -- error
+-- ALTER TABLE RENAME COLUMN should be blocked when column is used by
+-- a property graph (the property graph catalog stores property names
+-- that would become stale after the rename)
+
+CREATE TABLE rename_test (id int PRIMARY KEY, val text);
+CREATE PROPERTY GRAPH g_rename VERTEX TABLES (rename_test KEY (id));
+ALTER TABLE rename_test RENAME COLUMN val TO new_val; -- error
+ALTER TABLE rename_test RENAME COLUMN id TO new_id; -- error (KEY column)
+-- renaming a column not used by the graph should still work
+ALTER TABLE rename_test ADD COLUMN extra int;
+ALTER TABLE rename_test RENAME COLUMN extra TO extra2; -- ok
+ALTER TABLE rename_test DROP COLUMN extra2;
+DROP PROPERTY GRAPH g_rename;
+DROP TABLE rename_test;
+
+
-- DROP, ALTER SET SCHEMA, ALTER PROPERTY GRAPH RENAME TO
DROP TABLE g2; -- error: wrong object type
--
2.43.0
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [Patch] Block ALTER TABLE RENAME COLUMN when column is used by property graph
@ 2026-04-23 07:32 Ashutosh Bapat <[email protected]>
parent: SATYANARAYANA NARLAPURAM <[email protected]>
0 siblings, 2 replies; 6+ messages in thread
From: Ashutosh Bapat @ 2026-04-23 07:32 UTC (permalink / raw)
To: SATYANARAYANA NARLAPURAM <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
On Thu, Apr 23, 2026 at 12:23 PM SATYANARAYANA NARLAPURAM
<[email protected]> wrote:
>
> Hi hackers,
>
> When a table column is referenced by a property graph, the property
> name stored in pg_propgraph_property.pgpname would become stale after
> a column rename. This caused GRAPH_TABLE queries to fail with the new
> column name ("property does not exist") while the old (dead) name
> continued to work. pg_get_propgraphdef() would also emit confusing
> output like "new_col AS old_col".
This behaviour is inline with the behaviour of view.
#create view vt as select a from t1;
CREATE VIEW
#\d+ vt
View "public.vt"
Column | Type | Collation | Nullable | Default | Storage | Description
--------+---------+-----------+----------+---------+---------+-------------
a | integer | | | | plain |
View definition:
SELECT a
FROM t1;
#alter table t1 rename column a TO aa;
ALTER TABLE
#\d+ vt
View "public.vt"
Column | Type | Collation | Nullable | Default | Storage | Description
--------+---------+-----------+----------+---------+---------+-------------
a | integer | | | | plain |
View definition:
SELECT aa AS a
FROM t1;
Name of the property is derived from the name of the column it
references if the property name is not specified at the time of
creating the property. But these two are different. Changing column
name can not be expected to change the property name automatically. If
two elements have the same label, the set of property names associated
with that label is expected to be the same for those two elements as
well.
--
Best Wishes,
Ashutosh Bapat
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [Patch] Block ALTER TABLE RENAME COLUMN when column is used by property graph
@ 2026-04-23 07:39 SATYANARAYANA NARLAPURAM <[email protected]>
parent: Ashutosh Bapat <[email protected]>
1 sibling, 1 reply; 6+ messages in thread
From: SATYANARAYANA NARLAPURAM @ 2026-04-23 07:39 UTC (permalink / raw)
To: Ashutosh Bapat <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
Hi
On Thu, Apr 23, 2026 at 12:33 AM Ashutosh Bapat <
[email protected]> wrote:
> On Thu, Apr 23, 2026 at 12:23 PM SATYANARAYANA NARLAPURAM
> <[email protected]> wrote:
> >
> > Hi hackers,
> >
> > When a table column is referenced by a property graph, the property
> > name stored in pg_propgraph_property.pgpname would become stale after
> > a column rename. This caused GRAPH_TABLE queries to fail with the new
> > column name ("property does not exist") while the old (dead) name
> > continued to work. pg_get_propgraphdef() would also emit confusing
> > output like "new_col AS old_col".
>
> This behaviour is inline with the behaviour of view.
>
> #create view vt as select a from t1;
> CREATE VIEW
> #\d+ vt
> View "public.vt"
> Column | Type | Collation | Nullable | Default | Storage | Description
> --------+---------+-----------+----------+---------+---------+-------------
> a | integer | | | | plain |
> View definition:
> SELECT a
> FROM t1;
>
> #alter table t1 rename column a TO aa;
> ALTER TABLE
> #\d+ vt
> View "public.vt"
> Column | Type | Collation | Nullable | Default | Storage | Description
> --------+---------+-----------+----------+---------+---------+-------------
> a | integer | | | | plain |
> View definition:
> SELECT aa AS a
> FROM t1;
>
> Name of the property is derived from the name of the column it
> references if the property name is not specified at the time of
> creating the property. But these two are different. Changing column
> name can not be expected to change the property name automatically. If
> two elements have the same label, the set of property names associated
> with that label is expected to be the same for those two elements as
> well.
Ashutosh, should we document this or it is a well known fact and not
needed? Asking in the context of Graphs, not views.
Thanks,
Satya
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [Patch] Block ALTER TABLE RENAME COLUMN when column is used by property graph
@ 2026-04-23 09:29 Ashutosh Bapat <[email protected]>
parent: SATYANARAYANA NARLAPURAM <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Ashutosh Bapat @ 2026-04-23 09:29 UTC (permalink / raw)
To: SATYANARAYANA NARLAPURAM <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
On Thu, Apr 23, 2026 at 1:09 PM SATYANARAYANA NARLAPURAM
<[email protected]> wrote:
>
> Hi
>
> On Thu, Apr 23, 2026 at 12:33 AM Ashutosh Bapat <[email protected]> wrote:
>>
>> On Thu, Apr 23, 2026 at 12:23 PM SATYANARAYANA NARLAPURAM
>> <[email protected]> wrote:
>> >
>> > Hi hackers,
>> >
>> > When a table column is referenced by a property graph, the property
>> > name stored in pg_propgraph_property.pgpname would become stale after
>> > a column rename. This caused GRAPH_TABLE queries to fail with the new
>> > column name ("property does not exist") while the old (dead) name
>> > continued to work. pg_get_propgraphdef() would also emit confusing
>> > output like "new_col AS old_col".
>>
>> This behaviour is inline with the behaviour of view.
>>
>> #create view vt as select a from t1;
>> CREATE VIEW
>> #\d+ vt
>> View "public.vt"
>> Column | Type | Collation | Nullable | Default | Storage | Description
>> --------+---------+-----------+----------+---------+---------+-------------
>> a | integer | | | | plain |
>> View definition:
>> SELECT a
>> FROM t1;
>>
>> #alter table t1 rename column a TO aa;
>> ALTER TABLE
>> #\d+ vt
>> View "public.vt"
>> Column | Type | Collation | Nullable | Default | Storage | Description
>> --------+---------+-----------+----------+---------+---------+-------------
>> a | integer | | | | plain |
>> View definition:
>> SELECT aa AS a
>> FROM t1;
>>
>> Name of the property is derived from the name of the column it
>> references if the property name is not specified at the time of
>> creating the property. But these two are different. Changing column
>> name can not be expected to change the property name automatically. If
>> two elements have the same label, the set of property names associated
>> with that label is expected to be the same for those two elements as
>> well.
>
>
> Ashutosh, should we document this or it is a well known fact and not needed? Asking in the context of Graphs, not views.
I don't think we need to document it.
--
Best Wishes,
Ashutosh Bapat
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [Patch] Block ALTER TABLE RENAME COLUMN when column is used by property graph
@ 2026-04-23 13:49 Álvaro Herrera <[email protected]>
parent: Ashutosh Bapat <[email protected]>
1 sibling, 1 reply; 6+ messages in thread
From: Álvaro Herrera @ 2026-04-23 13:49 UTC (permalink / raw)
To: Ashutosh Bapat <[email protected]>; +Cc: SATYANARAYANA NARLAPURAM <[email protected]>; PostgreSQL Hackers <[email protected]>
On 2026-Apr-23, Ashutosh Bapat wrote:
> Name of the property is derived from the name of the column it
> references if the property name is not specified at the time of
> creating the property. But these two are different. Changing column
> name can not be expected to change the property name automatically.
Hmm, but we do rename constraints when we rename indexes, and other
similar things, don't we?
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"No me acuerdo, pero no es cierto. No es cierto, y si fuera cierto,
no me acuerdo." (Augusto Pinochet a una corte de justicia)
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [Patch] Block ALTER TABLE RENAME COLUMN when column is used by property graph
@ 2026-04-24 04:26 Ashutosh Bapat <[email protected]>
parent: Álvaro Herrera <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Ashutosh Bapat @ 2026-04-24 04:26 UTC (permalink / raw)
To: Álvaro Herrera <[email protected]>; +Cc: SATYANARAYANA NARLAPURAM <[email protected]>; PostgreSQL Hackers <[email protected]>
On Thu, Apr 23, 2026 at 7:19 PM Álvaro Herrera <[email protected]> wrote:
>
> On 2026-Apr-23, Ashutosh Bapat wrote:
>
> > Name of the property is derived from the name of the column it
> > references if the property name is not specified at the time of
> > creating the property. But these two are different. Changing column
> > name can not be expected to change the property name automatically.
>
> Hmm, but we do rename constraints when we rename indexes, and other
> similar things, don't we?
>
Properties are much closer to the view columns compared to
constraints. I am not able to see the significance of this comparison.
But more important is the reason mentioned in the last sentence of my
response which you have not included in your reply.
"If two elements have the same label, the set of property names
associated with that label is expected to be the same for those two
elements as well." .
A property is associated with an element table through one or more
labels. These labels in turn can be associated with more than one
element. Every element associated with a given label has to define the
same set of properties (names and types). When there is only one
element defining a given property it may appear that the property name
is linked to the column name if the first was derived from the latter.
But that's not true when multiple elements define the same property.
Unlike a constraint or an index, a property is not associated with
only one table - it can be associated with multiple tables. Hence
changing property name as a result of changing name of a column is not
correct.
--
Best Wishes,
Ashutosh Bapat
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-04-24 04:26 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-04-23 06:53 [Patch] Block ALTER TABLE RENAME COLUMN when column is used by property graph SATYANARAYANA NARLAPURAM <[email protected]>
2026-04-23 07:32 ` Ashutosh Bapat <[email protected]>
2026-04-23 07:39 ` SATYANARAYANA NARLAPURAM <[email protected]>
2026-04-23 09:29 ` Ashutosh Bapat <[email protected]>
2026-04-23 13:49 ` Álvaro Herrera <[email protected]>
2026-04-24 04:26 ` Ashutosh Bapat <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox