Re: PL/pgSQL 1.2

Поиск
Список
Период
Сортировка
От Marko Tiikkaja
Тема Re: PL/pgSQL 1.2
Дата
Msg-id 540A7085.9080008@joh.to
обсуждение исходный текст
Ответ на Re: PL/pgSQL 1.2  (Marko Tiikkaja <marko@joh.to>)
Ответы Re: PL/pgSQL 1.2  (Pavel Stehule <pavel.stehule@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Zhaomo Yang
Дата:
Сообщение: Re: A mechanism securing web applications in DBMS
Следующее
От: Marko Tiikkaja
Дата:
Сообщение: Re: PL/pgSQL 2