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

From: "Martijn Tonies \(Upscene Productions\)" <m(dot)tonies(at)upscene(dot)com>
To: "Dominique Devienne" <ddevienne(at)gmail(dot)com>, <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Stored procedure code no longer stored in v14 and v15, changed behaviour
Date: 2022-12-02 07:49:32
Message-ID: 661B1D571A89455FAE64C8F316D1EAA3@MARTIJNWS
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ludwig Isaac Lim 2022-12-02 08:45:06 ERROR : cannot commit while a portal is pinned from plpython
Previous Message yang zhao 2022-12-02 04:40:21 sort performance better with little memory than big memory