Re: default_language

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: default_language
Date: 2010-01-25 02:13:34
Message-ID: 1264385614.13571.14.camel@ebony
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 2010-01-24 at 23:59 +0000, Greg Stark wrote:
> On Sun, Jan 24, 2010 at 11:18 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> > I would prefer having the option, but removing it completely does at
> > least solve the bizarre inconsistency I've highlighted.
> >
>
> I don't see it as much of an inconsistency. The whole point of DO is
> to be convenient, whereas CREATE FUNCTION is DDL for defining what
> your database looks like and it should be well defined in perpetuity.

So you want your database to work declaratively, but the code that runs
against it doesn't need to be. Why would that be? What advantage is
gained from having DO blocks potentially fail sometime in the future?
Whatever that advantage is, why should functions not also be able to
take advantage of that same benefit?

> However it's also possible will write DO blocks into their application
> code in which case it might be preferable not to have a
> default_language GUC which would have to be set correctly for the code
> to work.

--
Simon Riggs www.2ndQuadrant.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Takahiro Itagaki 2010-01-25 02:16:23 Syntax supplements for SET options
Previous Message Kevin Grittner 2010-01-25 01:46:25 Re: commit fests