Re: What Am I missing?

From: William Robertson <>
Date: Tue, 8 Sep 2020 14:04:46 +0100
Message-Id: <>

That will work in this particular case, assuming the script contains exactly one object definition and nothing else, and we don't mind losing blank lines.

But I can create the function in PL/SQL Developer anyway, so the problem only arises when the source code file is run using SQL*Plus as part of a deployment. If we have some deployment framework that calls SQL*Plus and we change it to get & run everything, it will then fail on other scripts that contain multiple statements. Or if we change this particular script to get & run itself that could work, but it would be less effort just to move the slash character, and we would still have our blank lines.

Anyway the point I was making was that it's unfair to blame the PL/SQL parser, which I felt was somewhat implied by "It's a PL/SQL parser bug." It's more of a limitation of a CLI that needs a "stop input and execute" character which happens to be the same as a language operator. You’d hit the same issue with a SQL statement.


On 8 Sep 2020, at 10:40, Sayan Malakshinov <> wrote:

Hi William,

As I said previously that's just a problem of command processing with pretty easy workaround: just save your ddl as a script and use `get file.sql` command to put its content into the buffer and run using /

On Tue, Sep 8, 2020 at 12:34 PM William Robertson < <>> wrote: I wouldn't call it a PL/SQL parser bug. The client tool doesn't know it's PL/SQL and splits the code at the / character, producing an incomplete function followed by some unparsable lines which never reach the PL/SQL compiler. I'm amazed that I've never seen this before but I can reproduce it in SQL*Plus

I'm not sure what else SQL*Plus could do, to be honest, as / means run and there is no way to change it.



Best regards,
Sayan Malakshinov
Oracle performance tuning engineer
Oracle ACE Associate <>

-- Received on Tue Sep 08 2020 - 15:04:46 CEST

Original text of this message