Re: [GENERAL] LYDB: What advice about stored procedures and other server side code?

2016-12-29 Thread Adrian Klaver
On 12/29/2016 02:12 AM, Christoph Moench-Tegeder wrote: ## Karsten Hilbert (karsten.hilb...@gmx.net): Many applications are not designed to have a "stable" database API. It seems OP is arguing they should. Well, if the environment allows for that, fine. If not, well, duh. Been following al

Re: [GENERAL] LYDB: What advice about stored procedures and other server side code?

2016-12-29 Thread Christoph Moench-Tegeder
## Karsten Hilbert (karsten.hilb...@gmx.net): > > Many applications are not designed to have a "stable" database API. > It seems OP is arguing they should. Well, if the environment allows for that, fine. If not, well, duh. Regards, Christoph -- Spare Space -- Sent via pgsql-general mailing

Re: [GENERAL] LYDB: What advice about stored procedures and other server side code?

2016-12-28 Thread Karsten Hilbert
> Many applications are not designed to have a "stable" database API. It seems OP is arguing they should. Regards, Karsten -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] LYDB: What advice about stored procedures and other server side code?

2016-12-28 Thread Christoph Moench-Tegeder
## Mike Sofen (mso...@runbox.com): > I look at this from the opposite direction: with a stable database > API (via stored procs), I can change the schema and logic within the > procs without causing any app code breakage…the app tier is completely > insulated from those changes – that’s worth a lo

Re: [GENERAL] LYDB: What advice about stored procedures and other server side code?

2016-12-28 Thread Mike Sofen
|From: Christoph Moench-Tegeder |Initially, running code in your database can make life easier for the developers |(ise pgTap for testing, pl/profiler and pl/debugger, etc.). But once you have to |change your schema, the hurt begins: |you'll need downtime for that, or you'll have to deal with the

Re: [GENERAL] LYDB: What advice about stored procedures and other server side code?

2016-12-28 Thread Pavel Stehule
2016-12-28 16:12 GMT+01:00 Christoph Moench-Tegeder : > ## Guyren Howe (guy...@gmail.com): > > > I am inclined to advise folks to use PL/V8 on Postgres, because it is > > a reasonable language, everyone knows it, it has good string functions, > > decent performance and it tends to be installed eve

Re: [GENERAL] LYDB: What advice about stored procedures and other server side code?

2016-12-28 Thread Christoph Moench-Tegeder
## Guyren Howe (guy...@gmail.com): > I am inclined to advise folks to use PL/V8 on Postgres, because it is > a reasonable language, everyone knows it, it has good string functions, > decent performance and it tends to be installed everywhere (in particular, > Amazon RDF offers it). I'd be careful

Re: [GENERAL] LYDB: What advice about stored procedures and other server side code?

2016-12-27 Thread Alban Hertroys
> On 27 Dec 2016, at 23:03, Guyren Howe 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 th

Re: [GENERAL] LYDB: What advice about stored procedures and other server side code?

2016-12-27 Thread Steve Atkins
> On Dec 27, 2016, at 2:03 PM, Guyren Howe 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

[GENERAL] LYDB: What advice about stored procedures and other server side code?

2016-12-27 Thread Guyren Howe
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 has emerged, tend to treat their database server as a dum