agora inbox for pgsql-committers@postgresql.orghelp / color / mirror / Atom feed
pgsql: Report duplicate property and label names with a proper error 2+ messages / 1 participants [nested] [flat]
* pgsql: Report duplicate property and label names with a proper error @ 2026-08-06 08:43 Peter Eisentraut <peter@eisentraut.org> 0 siblings, 0 replies; 2+ messages in thread From: Peter Eisentraut @ 2026-08-06 08:43 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Report duplicate property and label names with a proper error Adding a property with the same name multiple times to a label on an element, either within a single PROPERTIES clause or across statements via ALTER PROPERTY GRAPH ... ADD PROPERTIES, previously failed with a unique-index violation on pg_propgraph_label_property. The same class of bug existed for labels: listing the same label multiple times on one element in CREATE PROPERTY GRAPH, or adding a label to an element that already has it via ALTER PROPERTY GRAPH ... ADD LABEL, failed with a unique-index violation on pg_propgraph_element_label. Detect the duplicates up front and raise a friendlier error in both cases. For properties, the cross-statement duplicate is caught by a syscache probe before insertion. The in-clause duplicate could have been caught by the same probe if we issued a CommandCounterIncrement() between property inserts, but that forces a catalog invalidation per property purely to detect a condition we can check for free on the in-memory target list. The list-based check is only needed when the properties are listed explicitly; when they are derived from the table's attributes, names are already unique. For labels, a single syscache probe on pg_propgraph_element_label suffices for both the in-clause and cross-statement cases because insert_element_record() already issues CommandCounterIncrement() between successive label inserts. Author: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> Reported-by: Noah Misch <noah@leadboat.com> Discussion: https://www.postgresql.org/message-id/flat/20260630173053.51.noahmisch%40microsoft.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/9b917a93116e6b8aac7ed837ded27696f7232505 Modified Files -------------- src/backend/commands/propgraphcmds.c | 37 ++++++++++++++++++++-- .../regress/expected/create_property_graph.out | 14 ++++++++ src/test/regress/sql/create_property_graph.sql | 12 +++++++ 3 files changed, 60 insertions(+), 3 deletions(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
* pgsql: Report duplicate property and label names with a proper error @ 2026-08-06 08:43 Peter Eisentraut <peter@eisentraut.org> 0 siblings, 0 replies; 2+ messages in thread From: Peter Eisentraut @ 2026-08-06 08:43 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Report duplicate property and label names with a proper error Adding a property with the same name multiple times to a label on an element, either within a single PROPERTIES clause or across statements via ALTER PROPERTY GRAPH ... ADD PROPERTIES, previously failed with a unique-index violation on pg_propgraph_label_property. The same class of bug existed for labels: listing the same label multiple times on one element in CREATE PROPERTY GRAPH, or adding a label to an element that already has it via ALTER PROPERTY GRAPH ... ADD LABEL, failed with a unique-index violation on pg_propgraph_element_label. Detect the duplicates up front and raise a friendlier error in both cases. For properties, the cross-statement duplicate is caught by a syscache probe before insertion. The in-clause duplicate could have been caught by the same probe if we issued a CommandCounterIncrement() between property inserts, but that forces a catalog invalidation per property purely to detect a condition we can check for free on the in-memory target list. The list-based check is only needed when the properties are listed explicitly; when they are derived from the table's attributes, names are already unique. For labels, a single syscache probe on pg_propgraph_element_label suffices for both the in-clause and cross-statement cases because insert_element_record() already issues CommandCounterIncrement() between successive label inserts. Author: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> Reported-by: Noah Misch <noah@leadboat.com> Discussion: https://www.postgresql.org/message-id/flat/20260630173053.51.noahmisch%40microsoft.com Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/22d0eebfef780b21c4e5a16966eff59fb7a9b9d6 Modified Files -------------- src/backend/commands/propgraphcmds.c | 37 ++++++++++++++++++++-- .../regress/expected/create_property_graph.out | 14 ++++++++ src/test/regress/sql/create_property_graph.sql | 12 +++++++ 3 files changed, 60 insertions(+), 3 deletions(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-08-06 08:43 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-08-06 08:43 pgsql: Report duplicate property and label names with a proper error Peter Eisentraut <peter@eisentraut.org> 2026-08-06 08:43 pgsql: Report duplicate property and label names with a proper error Peter Eisentraut <peter@eisentraut.org>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox