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

From: Dominique Devienne <ddevienne(at)gmail(dot)com>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: "Martijn Tonies (Upscene Productions)" <m(dot)tonies(at)upscene(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 13:39:03
Message-ID: CAFCRh--YRinDnUPAKrZuxj3R1RdQZRVAk8dZQy0i_W1DKHrNwA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, Dec 2, 2022 at 1:37 PM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:
> Great; then go ahead and use those databases, if it is important for you.

Now come on. We all love PostgreSQL.
But that doesn't mean we can't disagree on some decisions.

Especially when you are a USER of PostgreSQL, not a DEV of it,
and it's too late by the time you are even aware of the changes.
Not everyone can chime in on the dev-list when those are discussed.

From a user point of view, can also be seen as a "regression",
when an observable property of the system changes to a new
different / incompatible way, to some extent. I'm not saying it is,
still it is a change one discovers too late, creates pain to some,
and is both worth reporting and discussing.

Given the tone of the discussion here though,
I don't think there's much to hope for a middle ground...

> In the same vein, I don't think any of those databases have ... bloom indexes.

SQLite has bloom filters now :) (not persistent indexes)

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message raf 2022-12-02 13:47:17 Re: Stored procedure code no longer stored in v14 and v15, changed behaviour
Previous Message Pasi Oja-Nisula 2022-12-02 13:34:39 Re: Stored procedure code no longer stored in v14 and v15, changed behaviour