| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | Dominique Devienne <ddevienne(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, "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-01 16:10:27 |
| Message-ID: | c14b49a2043adafbe9589fab7af4eceb6199726c.camel@cybertec.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Thu, 2022-12-01 at 16:38 +0100, Dominique Devienne wrote:
> FWIW, we have a custom schema introspection and diff'ing ad-hoc framework,
> and the fact the original SQL is not conserved as-is has also created
> issues for us.
>
> On Oracle, our SQL was preserved as-is, so could be compared reliably. While on
> PostgreSQL, some names-in-SQL are rewritten, the text reformatted,
> etc...
>
> So it's not just a matter of browsing the schema. For us, it's a
> *functional* issue. --DD
This is arguable, but my opinion is that this is not a robust way to
do development. You should use a schema versioning tool like Liquibase,
develop schema migration scripts and maintain the SQL code in a source
repository like other software.
At any rate, you won't be able to do it in your accustomed way in
PostgreSQL.
Yours,
Laurenz Albe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Loftis | 2022-12-01 16:21:08 | Re: postgres large database backup |
| Previous Message | Martijn Tonies (Upscene Productions) | 2022-12-01 15:40:11 | Re: Stored procedure code no longer stored in v14 and v15, changed behaviour |