Re: PL/pgSQL 1.2 - Mailing list pgsql-hackers

From Marko Tiikkaja
Subject Re: PL/pgSQL 1.2
Date
Msg-id 540A7085.9080008@joh.to
Whole thread Raw
In response to Re: PL/pgSQL 1.2  (Marko Tiikkaja <marko@joh.to>)
Responses Re: PL/pgSQL 1.2
List pgsql-hackers
On 2014-09-04 2:28 PM, I wrote:
> On 9/4/14 2:04 PM, Pavel Stehule wrote:
>> for example best practices for PL/SQL by Steven Feuerstein
>
> I'll spend some time with that book to have a better idea on where
> you're coming from.

I've read through this book twice now.  Some observations on things we 
don't follow:
  - We don't use the exact hungarian notation -ish convention for 
naming stuff.  I don't see that as a bad thing.  - Granted, we could be using the  myfield tablename.columnname%TYPE;
probablymore.  On the other hand, sometimes you would prefer to not 
 
have all your types in your functions change transparently after an 
ALTER TABLE.  - The book takes the "single exit point" thinking to an extreme.  I 
don't agree with that, regardless of the language (and thus I might not 
necessarily always follow it).  - The book says "Encapsulate INSERT, UPDATE, and DELETE statements 
behind procedure calls", which quite directly contradicts what you said 
earlier.

The rest of the stuff we follow in our codebase as far as I can tell 
(except the Oracle-specific stuff, obviously).

But further, even if we did follow every single one of the above points 
perfectly, it wouldn't change the point we're trying to make.  What 
we're doing is following what the book dedicated an entire chapter to: 
Defensive Programming.  Enforcing that that UPDATE affected exactly one 
row?  Defensive Programming.


.marko



pgsql-hackers by date:

Previous
From: Zhaomo Yang
Date:
Subject: Re: A mechanism securing web applications in DBMS
Next
From: Marko Tiikkaja
Date:
Subject: Re: PL/pgSQL 2