RE: Ways to "serialize" result set for later use? - Mailing list pgsql-general

From Kevin Brannen
Subject RE: Ways to "serialize" result set for later use?
Date
Msg-id SN6PR19MB235127DF3112A1FEAEB75BF0A44F9@SN6PR19MB2351.namprd19.prod.outlook.com
Whole thread Raw
In response to Re: Ways to "serialize" result set for later use?  (Adam Brusselback <adambrusselback@gmail.com>)
List pgsql-general

From: Adam Brusselback <adambrusselback@gmail.com>
Sent: Monday, April 12, 2021 12:51 PM

 

>  Checking data (DML), if functions are doing the right things is something we do in our code unit tests.

 

This is exactly what I am writing, unit tests for my code (which is pl/pgsql). This is an ELT pipeline for my customers to bulk update their data in my system, with detailed error reporting for any issues per-row/column. The code is all plpgsql, as are the few tests i've written so far. pgTAP is my unit testing framework for this process.

 

So unit testing my company's (vast) database code is something I am just trying to figure out and get into my workflow, and it didn't feel like I had to fight too hard with it at this point, other than $subject$. And even that isn't an issue with my hacky function in place, it just feels a little...dirty I guess? Was just wanting a gut check if there seemed to be an obviously better way to get the same results.

 

If there is something built into Pg that does what you want, I'm not aware of it, but there are a number of extensions out there. You could check out that list to see.

 

Otherwise, I'm not sure we can help you much. If that approach seems to be working, continue on and see where it takes you.

 

Our unit tests are in Perl based on a module we created that inherits from Test::More. From there, we can exercise any code we need, many of which contains calls to DB functions, injecting known values for all the use cases we can think of, and making sure we get back the expected results. That also means we can COPY data in for testing if required. It's pretty simplistic and straight-forward in some ways, but it works for us.

 

HTH,

Kevin

.

This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential information. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, distribution, review, copy or use of any of the information contained in or attached to this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify us by reply e-mail, and destroy the original transmission and its attachments without reading them or saving them to disk. Thank you.

pgsql-general by date:

Previous
From: Dmitry Koterov
Date:
Subject: Suboptimal plan when IN(...), ORDER BY and LIMIT are used (no JOINs)
Next
From: Kevin Brannen
Date:
Subject: RE: [Extern] Re: Advice on binary installation