Debugging with PostgreSQL – A Strategic (& Streamlined) Approach
As planned, I gave a talk on Debugging with PostgreSQL at the Philly PostgreSQL conference at Wharton this last Friday (7/19/2019).
Went well: debugging is a great subject & I definitely struck a nerve with the audience; after the talk people were saying they knew about some of the points — which gave them some confidence — and others were new — which gave them some tools. Good.
My most popular slide was a quiz: only 10 lines of code — and from the PostgreSQL man page on foreign keys — but still three bugs. For the record, they are:
- All of the data types should be domains, not physical types, so the city type should be something like “city_t”, defined as varchar(80). And the temperature should be, say, “fahrenheit_t” (or “celsius_t”), so you know what the units are.
- The use of key words, like “date”, for field names is not great technique. It is ambiguous at best; breaks stuff at worst.
- And the width for the city is way too small. Consider the name of Bangkok in Thai, the language of Bangkok: Krungthepmahanakhon Amonrattanakosin Mahintharayutthaya Mahadilokphop Noppharatratchathaniburirom Udomratchaniwetmahasathan Amonphimanawatansathit Sakkathattiyawitsanukamprasit. 177 characters! If you make the city’s type a domain, then you can revise the domain to be, say, “text” — and automagically get the type fixed everywhere you have a city reference.
I was scheduled to go late morning but went first because the opening speaker was still at his hotel. As a result I had the pleasant experience of hearing several later speakers refer to points made in my talk. The most popular was the phrase “lie consistently“.
I had built a form to collect Social Security numbers when I was at Bellcore (now Telcordia). It blew up when one fellow put in a variety of SSNs. I asked him what was going on. He said “I don’t want Bellcore to have my SSN. They have no legal right to it!”. “Fine by me, but just do me a favor & lie consistently“. We both left happy.
I did a run thru of the talk Sunday with my OTC (Official Talk Consultant); she pointed out, with her usual correctness, that I had tried to fit an entire software engineering course into 50 minutes. As a result, the early mornings & late evenings Monday thru Wednesday were spent reorganizing & rewriting. A 2nd run thru Wednesday evening went much better. OTC approved.
But when I did a final final talk & schedule check Friday morning I found the time blocks were now down to 40 minutes. Snip, snip, cut, cut, squeeze, squeeze. I cut out everything that wasn’t on message, useful, & fun. Definitely improved the talk. That which does not destroy us makes us strong. Or at least succinct.
Final version of the talk (PDF): Debugging with PostgreSQL — A Strategic (& Streamlined!) Approach.