Re: Stored procedure code no longer stored in v14 and v15, changed behaviour - Mailing list pgsql-general

From Martijn Tonies \(Upscene Productions\)
Subject Re: Stored procedure code no longer stored in v14 and v15, changed behaviour
Date
Msg-id 661B1D571A89455FAE64C8F316D1EAA3@MARTIJNWS
Whole thread Raw
In response to Re: Stored procedure code no longer stored in v14 and v15, changed behaviour  (Dominique Devienne <ddevienne@gmail.com>)
Responses Re: Stored procedure code no longer stored in v14 and v15, changed behaviour  (Laurenz Albe <laurenz.albe@cybertec.at>)
List pgsql-general
>> On 12/1/22 09:24, Dominique Devienne wrote:
>> > I guess is a DBA-versus-Developer point-of-view difference. --DD
>>
>> What this points to is that there are multiple ways to handle this, many
>> external to the server itself. My take is that the system catalogs are
>> there for the proper operation of the server and that is their task,
>> first and foremost. If you can piggyback of that then great, but with
>> the knowledge that the information may change to meet the needs of the
>> server not external users.
>
>I see. Still, Oracle preserves SQL as-is. SQLite preserve SQL as-is.
>Would be nice if PostgreSQL did too. That's all I'm saying.

So do InterBase, Firebird, SQL Server, MySQL (except for Views, strangely 
enough),
MariaDB, NexusDB, SQL Anywhere, and, frankly, all others I know of.

And this is used all the time by database developers.

And at least InterBase and Firebird -also- stored a 'parsed version' (in 
binary).


With regards,

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

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




pgsql-general by date:

Previous
From: yang zhao
Date:
Subject: sort performance better with little memory than big memory
Next
From: Ludwig Isaac Lim
Date:
Subject: ERROR : cannot commit while a portal is pinned from plpython