Re: Stored procedure code no longer stored in v14 and v15, changed behaviour

["Martijn Tonies \(Upscene Productions\)" <m.tonies@xxxxxxxxxxx>]

On Thu, Dec 1, 2022 at 7:59 AM Martijn Tonies (Upscene Productions) <m.tonies@xxxxxxxxxxx> wrote:

Since version 14, the source code for a stored procedure or function written
in plain (compound) SQL, a new feature, is no longer stored in
pg_proc.prosrc, instead, there’s an additional column prosqlbody which
returns some kind of pre-parsed SQL which has no use for the user.

 

For database
development, including browsing an existing database and know what each
routine can do, this is quite terrible.

 

Frankly, this is not all that compelling.  The version controlled source code should be readily referenced to find out the extended details of this nature.  The function name, and a COMMENT ON comment, provide arguably sufficient in-database knowledge for cursory browsing redirecting the reader to the source code for implementation details and history.

 

 

Frankly, David, you’re wrong. Although I agree a version controlled source code is a very good way to maintain a proper version of your development database, –while- developing and changing source code, it’s simply not the easiest way to run scripts, compared to having a tool that allows more interactive development, code commenting (instead of “COMMENT ON”), SQL Insight, browsing the current structure and so on.

 

 

 

 

Can you modify the server code to store the original body in proc.prosrc
again? It would be very helpful.

 

I seem to recall that this option had been discussed and rejected when this feature went in.  The parsed body is a feature because its contents can be updated due to, e.g., renaming of objects.  The text source of the original command would be unable to be updated in the same way and so it is possible the text and the parsed contents would diverge over time, which is a situation we do not want to have.

 

 

Ah yes, automatic renaming of database objects with its dependencies can be useful. Oracle invalidates routines that use the objects, marks those routines ‘invalid’ and they need to be recompiled, that would fail when the source code references an object that no longer exists. This also means that you actually know which files you need to touch in your version controlled source

 

With regards,

Martijn Tonies
Upscene Productions
https://www.upscene.com

Database Workbench - developer tool for Oracle, SQL Server, PostgreSQL, MySQL, InterBase, NexusDB and Firebird.