Horton
Menu

Thread

  1. [Patch] Block ALTER TABLE RENAME COLUMN when column is used by property graph

    SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com> — 2026-04-23T06:53:45Z

    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

  2. Re: [Patch] Block ALTER TABLE RENAME COLUMN when column is used by property graph

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2026-04-23T07:32:47Z

    On Thu, Apr 23, 2026 at 12:23 PM SATYANARAYANA NARLAPURAM
<satyanarlapuram@gmail.com> 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

  3. Re: [Patch] Block ALTER TABLE RENAME COLUMN when column is used by property graph

    SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com> — 2026-04-23T07:39:01Z

    Hi

On Thu, Apr 23, 2026 at 12:33 AM Ashutosh Bapat <
ashutosh.bapat.oss@gmail.com> wrote:

> On Thu, Apr 23, 2026 at 12:23 PM SATYANARAYANA NARLAPURAM
> <satyanarlapuram@gmail.com> 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

  4. Re: [Patch] Block ALTER TABLE RENAME COLUMN when column is used by property graph

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2026-04-23T09:29:49Z

    On Thu, Apr 23, 2026 at 1:09 PM SATYANARAYANA NARLAPURAM
<satyanarlapuram@gmail.com> wrote:
>
> Hi
>
> On Thu, Apr 23, 2026 at 12:33 AM Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> wrote:
>>
>> On Thu, Apr 23, 2026 at 12:23 PM SATYANARAYANA NARLAPURAM
>> <satyanarlapuram@gmail.com> 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

  5. Re: [Patch] Block ALTER TABLE RENAME COLUMN when column is used by property graph

    Álvaro Herrera <alvherre@kurilemu.de> — 2026-04-23T13:49:46Z

    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)

  6. Re: [Patch] Block ALTER TABLE RENAME COLUMN when column is used by property graph

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2026-04-24T04:26:54Z

    On Thu, Apr 23, 2026 at 7:19 PM Álvaro Herrera <alvherre@kurilemu.de> 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