In this blog post, we will look at one type of ‘conditional formatting’ that enables you to perform complex calculations. PostgreSQL (and SQL in general) provides us with a couple of variants of the CASE statement which could be used for this very thing, among many many others. Learn with me as I make my way through writing this post…

Photo by Nikita Tikhomirov on Unsplash

Note: All data, names or naming found within the database presented in this post, are strictly used for practice, learning, instruction, and testing purposes. It by no means depicts actual data belonging to or being used by any party or organization.

Xubuntu Linux 18.04.2 LTS (Bionic Beaver)

PostgreSQL 11.2

Self-Promotion:

OS and DB used:

If you enjoy the content written here, by all means, share this blog and your favorite post(s) with others who may benefit from or like it as well. Since coffee is my favorite drink, you can even buy me one if you would like!

I’ll use a couple of tables from the PostgreSQL practice DVD Rental database for the example queries below.

Let’s start off with a base query to determine which customers spent more than 150.00 on DVD rentals:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

SELECT c.first_name, c.last_name, sum ( p.amount )

FROM customer AS c

INNER JOIN payment AS p

ON c.customer_id = p.customer_id

GROUP by c.first_name, c.last_name

HAVING SUM ( p.amount ) > 150 ;

first_name | last_name | sum

------------+-----------+--------

Lena | Jensen | 154.70

Tommy | Collazo | 183.63

Ana | Bradley | 167.67

Clara | Shaw | 189.60

Brittany | Riley | 151.73

Warren | Sherrod | 152.69

Karl | Seal | 208.58

Arnold | Havens | 161.68

Mike | Way | 162.67

Wesley | Bull | 158.65

Gordon | Allard | 157.69

Marcia | Dean | 166.61

June | Carroll | 151.68

Tim | Cary | 154.66

Eleanor | Hunt | 211.55

Marion | Snyder | 194.61

Steve | Mackenzie | 152.68

Guy | Brownlee | 151.69

Curtis | Irby | 167.62

Louis | Leone | 156.66

Rhonda | Kennedy | 191.62

( 21 rows )

Perhaps for reporting purposes, we want to distinguish these customers with a level of some sort, according to their spendings. Maybe we are sending them a discount for an upcoming sale.

Something along the lines of…

Totals spent of 190 plus are ‘platinum’ members.

Amounts more than 170 but less than 190 are ‘gold’ members.

Spending totals ranging from 160 to 170 are ‘bronze’ members.

Finally, the ‘standard’ members are those who have met the greater than 150 criteria, yet have not quite eclipsed the 160 spending mark.

Let’s visit the below query for a breakdown of where they will be ‘classified’ according to the total amount spent. To return the desired results we listed out above, CASE is our friend. Let’s take a shot at it with this query:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

SELECT c.first_name, c.last_name, SUM ( p.amount ) ,

CASE

WHEN SUM ( p.amount ) > 190 THEN 'platinum'

WHEN SUM ( p.amount ) BETWEEN 170 AND 190 THEN 'gold'

WHEN SUM ( p.amount ) BETWEEN 160 AND 170 THEN 'bronze'

ELSE 'standard' END AS member_status

FROM customer AS c

INNER JOIN payment AS p

ON c.customer_id = p.customer_id

GROUP by c.first_name, c.last_name

HAVING SUM ( p.amount ) > 150 ;

first_name | last_name | sum | member_status

------------+-----------+--------+---------------

Lena | Jensen | 154.70 | standard

Tommy | Collazo | 183.63 | gold

Ana | Bradley | 167.67 | bronze

Clara | Shaw | 189.60 | gold

Brittany | Riley | 151.73 | standard

Warren | Sherrod | 152.69 | standard

Karl | Seal | 208.58 | platinum

Arnold | Havens | 161.68 | bronze

Mike | Way | 162.67 | bronze

Wesley | Bull | 158.65 | standard

Gordon | Allard | 157.69 | standard

Marcia | Dean | 166.61 | bronze

June | Carroll | 151.68 | standard

Tim | Cary | 154.66 | standard

Eleanor | Hunt | 211.55 | platinum

Marion | Snyder | 194.61 | platinum

Steve | Mackenzie | 152.68 | standard

Guy | Brownlee | 151.69 | standard

Curtis | Irby | 167.62 | bronze

Louis | Leone | 156.66 | standard

Rhonda | Kennedy | 191.62 | platinum

( 21 rows )

In the above query results, for each row, due to the WHEN/THEN clauses, a ‘member_status’ column is displayed (with a designated ‘label’) according to the SUM() spending amount. For instance, since the 3rd row SUM() value of 167.67 meets the WHEN/THEN conditional of BETWEEN 160 AND 170 , that row has a ‘member_status’ of bronze. The same applies to other rows in the result set according to those SUM() values and conditional checks.

The ELSE clause portion could be thought of as the ‘default’ and covers any other row that does not meet the boolean conditional check of the other WHEN/THEN clauses.

The complexity of just what can be accomplished with the searched CASE expression obviously goes way further than that of the simple example covered here. However, I hope that by reading this post, you have a general understanding of this form of CASE and can find a use case for it in your day-to-day workflow.

Like what you have read? See anything incorrect? Please comment below and thanks for reading!!!

Explore the official PostgreSQL 11 On-line Documentation for more information.

A Call To Action!

Thank you for taking the time to read this post. I truly hope you discovered something interesting and enlightening. Please share your findings here, with someone else you know who would get the same value out of it as well.

Visit the Portfolio-Projects page to see blog post/technical writing I have completed for clients.

Have I mentioned how much I love a cup of coffee?!?!

To receive email notifications (Never Spam) from this blog (“Digital Owl’s Prose”) for the latest blog posts as they are published, please subscribe (of your own volition) by clicking the ‘Click To Subscribe!’ button in the sidebar on the homepage! (Feel free at any time to review the Digital Owl’s Prose Privacy Policy Page for any questions you may have about: email updates, opt-in, opt-out, contact forms, etc…)

Be sure and visit the “Best Of” page for a collection of my best blog posts.

Josh Otwell has a passion to study and grow as a SQL Developer and blogger. Other favorite activities find him with his nose buried in a good book, article, or the Linux command line. Among those, he shares a love of tabletop RPG games, reading fantasy novels, and spending time with his wife and two daughters.

Disclaimer: The examples presented in this post are hypothetical ideas of how to achieve similar types of results. They are not the utmost best solution(s). The majority, if not all, of the examples provided, is performed on a personal development/learning workstation-environment and should not be considered production quality or ready. Your particular goals and needs may vary. Use those practices that best benefit your needs and goals. Opinions are my own.

Share this: Twitter

Facebook

LinkedIn

Email

More

Pinterest

Skype



Reddit

WhatsApp



