> On Aug 4, 2026, at 17:10, Peter Smith <smithpb2250@gmail.com> wrote:
>
> On Tue, Aug 4, 2026 at 6:26 PM Chao Li <li.evan.chao@gmail.com> wrote:
>>
>>
>>
>>> On Aug 4, 2026, at 13:11, Peter Smith <smithpb2250@gmail.com> wrote:
>>>
>>> Here's a patch to add another tab-completion rule for DROP PROPERTY GRAPH [1]
>>>
>>> The logic is the same as DROP MATERIALIZED VIEW [2] which has a very
>>> similar syntax.
>>>
>>> PSA v1.
>>>
>>> ======
>>> [1] https://www.postgresql.org/docs/19/sql-drop-property-graph.html
>>> [2] https://www.postgresql.org/docs/19/sql-dropmaterializedview.html
>>>
>>> Kind Regards,
>>> Peter Smith.
>>> Fujitsu Australia
>>> <v1-0001-tab-complete-for-DROP-PROPERTY-GRAPH.patch>
>>
>> I think you also need to handle “IF EXISTS”. With v1, MatchAny considers “IF” as a relation name, thus it suggests
"CASCADE RESTRICT”, and when “IF EXISTS” is given, it doesn’t suggest anything:
>> ```
>> evantest=# drop property graph if
>> CASCADE RESTRICT
>> evantest=# drop property graph if exists a
>>
>
> Yeah, this patch only added CASECADE|RESTRICT in a way that's
> compatible with many of the other DROPS...
>
> (As mentioned in the original post, I copied the same rules as seen in
> DROP MATERIALIZED VIEW)
>
> So, what you reported is definitely a problem, but IMO it's a separate
> problem beyond the scope for this little patch.
>
> There's a lot of existing code which won't behave correctly for your
> IF EXISTS...
>
> e.g. Try any of these:
> - DROP MATERIALIZED VIEW IF <tab>
> - DROP INDEX IF <tab>
> - DROP ACCESS METHOD IF <tab>
> - DROP EVENT TRIGGER IF <tab>
> etc...
Ah, I’m not aware of that. Looks like CREATE has the same problem. So, I won’t expect this patch to do anything
especially.
V1 looks good to me.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
