Re: [GENERAL] LYDB: What advice about stored procedures and otherserver side code? - Mailing list pgsql-general

From Steve Atkins
Subject Re: [GENERAL] LYDB: What advice about stored procedures and otherserver side code?
Date
Msg-id 6E61A838-8910-4086-AB90-FBBA479D15F8@blighty.com
Whole thread Raw
In response to [GENERAL] LYDB: What advice about stored procedures and other server side code?  (Guyren Howe <guyren@gmail.com>)
List pgsql-general
> On Dec 27, 2016, at 2:03 PM, Guyren Howe <guyren@gmail.com> wrote:
>
> I am putting together some advice for developers about getting the most out of SQL servers in general and Postgres in
particular.I have in mind the likes of most web developers, who through ignorance or a strange cultural preference that
hasemerged, tend to treat their database server as a dumb data bucket. 
>
> I call the project Love Your Database (LYDB). It is starting as a series of blog posts:
>
> https://medium.com/@gisborne/love-your-database-lydb-23c69f480a1d#.4jngp2rcb
> https://medium.com/@gisborne/love-your-database-simple-validations-68d5d6d0bbf3#.az4o2s152
>
> I would next like to cover server-side code such as stored procedures and triggers.
>
> I am inclined to advise folks to use PL/V8 on Postgres, because it is a reasonable language, everyone knows it, it
hasgood string functions, decent performance and it tends to be installed everywhere (in particular, Amazon RDF offers
it).
>

Think hard about the "impedance mismatch" between parts of the system.

pl/pgsql uses sql data types and operators, and so interfaces very cleanly with the rest of postgresql. pl/v8 uses
javascriptdata types and *for database related things* is likely to be a less perfect match to the rest of the system -
asit's translating (or, in some cases, failing to translate) between sql data types and javascript data types that may
notbe entirely compatible, or which may not exist at all. 

So if your functions are mostly doing databasey things, pl/pgsql may well be a better choice. If they're mostly doing
appythings, that just happen to be in the database, then pl/v8 may be a better choice (but so might just doing the work
inthe app, perhaps with some listen/notify assistance). 

Most of the functions I write are short trigger functions, or data wrapper/modification functions for migration or
makingbusiness logic available for SQL. For the majority of those I find pl/pgsql the best match (if I can't get away
withsql functions). 

If you're trying to convince people to get the most out of their database, pushing them towards pl/v8 as their first
choiceof embedded language might not be the best path. (That it might encourage them to write code to iterate through
tablesrather than taking advantage of SQL where they can might be a thing too). 

Cheers,
  Steve


> Broadly, what advice should I offer that isn’t obvious? Not just about PL/V8 but server side code in general.
>
> TIA



pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: [GENERAL] Generating sample data
Next
From: Rich Shepard
Date:
Subject: Re: [GENERAL] Generating sample data