psql: Fix CREATE SCHEMA scanning of nested routine bodies - Mailing list pgsql-hackers

From Chao Li
Subject psql: Fix CREATE SCHEMA scanning of nested routine bodies
Date
Msg-id 8E03BB8D-003D-4850-9772-5F8015A5A0C7@gmail.com
Whole thread
Responses Re: psql: Fix CREATE SCHEMA scanning of nested routine bodies
List pgsql-hackers
Hi,

While testing “[d51697484] Support more object types within CREATE SCHEMA”, I found an issue that seems to be a psql
regression.

See this repro:
```
evantest=# CREATE SCHEMA s CREATE VIEW begin AS SELECT 1;
evantest-# end;
WARNING:  there is no transaction in progress
CREATE SCHEMA
COMMIT
```

After the first CREATE SCHEMA line, the prompt changed from =# to -#, meaning psql appeared to be treating the view
name“begin" as the start of a BEGIN ... END block. After I typed “end;" on the second line, the server executed the
firstline properly, then executed the second line as “end;", producing the “no transaction” warning. So, although psql
waitedfor “end;", it still sent two statements to the server. This suggests a psql bug. 

I then went back to commit 404db8f9, the immediate parent of d51697484, and ran the same test:
```
evantest=# CREATE SCHEMA s CREATE VIEW begin AS SELECT 1;
CREATE SCHEMA
evantest=#
evantest=# select * from s.begin;
 ?column?
----------
        1
(1 row)
```

It created schema “s" and created a view named “begin" under “s". So this seems to confirm a psql regression introduced
byd51697484. 

Looking at psqlscan.l, d51697484 made BEGIN/END tracking apply to CREATE SCHEMA, which seems too broad. I think we
shouldonly track BEGIN ... END for CREATE SCHEMA after seeing CREATE [OR REPLACE] FUNCTION/PROCEDURE. Following this
direction,I tried to make a fix. 

I added some test cases, but I’m not sure whether 001_basic.pl is the right place for them. Should these tests be added
toa new file, say 040_psqlscan.pl? I saw src/test/regress/sql/create_schema.sql, but I believe that is for server-side
testing,so these client-side tests should not go there. Suggestions are appreciated. 

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/





Attachment

pgsql-hackers by date:

Previous
From: Andrei Lepikhov
Date:
Subject: Re: Show hashed SAOP decision in EXPLAIN
Next
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: [PATCH] Improving index selection for logical replication apply with replica identity full