Re: Are stored procedures/triggers common in your industry

From: raf <raf(at)raf(dot)org>
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Are stored procedures/triggers common in your industry
Date: 2022-04-21 23:12:38
Message-ID: YmHk5qajymooVgkz@raf.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Apr 21, 2022 at 08:42:10AM -0500, Alex Aquino <alex(at)efficiencygeek(dot)com> wrote:

> You mentioned testing, and reminds me of another benefit. Way faster, more
> reliable, cheaper to test on the DB side. Testing logic in SPs or SQL is
> much easier, especially when testing requires a sequence of calls for a use
> case. It is easier because of the DBs support for transactions. With
> transactions and state management built into the DB, a testing process can
> always revert to a reliable starting point and end point, thereby
> facilitating more dependable, automated test harnesses. The alternative
> done mostly now is testing via UIs or APIs where there is no inherent
> transaction management, so a lot of work goes into preparing the test bed
> to be a known state and introspecting the results to verify. This is
> usually done with some mix of manual and automated processes.

Actually, my full work tests take ages to run (~40m).
I know that mocking the db to make unit tests fast is popular,
but that's not helpful when the most important code being tested
is in the database. :-) It's more important to me that the tests
actually test everything than that they be fast.

But yes, being able to do complex system testing with transaction
rollback is great.

cheers,
raf

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Shaozhong SHI 2022-04-21 23:21:17 Configuration and performance of Postgres/PostGIS
Previous Message Radoslav Nedyalkov 2022-04-21 21:25:42 set column statistics to max does not help