Re: String manipulation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Pascal Polleunus <ppo(at)beeznest(dot)net>, pgsql-general(at)postgresql(dot)org, pativo <pativo(at)arcor(dot)de>
Subject: Re: String manipulation
Date: 2004-02-18 00:13:05
Message-ID: 19143.1077063185@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> I don't think it is good practice for a CHECK constraint to change its
> behavior based on a GUC variable.

You can develop comparable "failure scenarios" for any of the GUC
variables that affect query semantics --- timezone, sql_inheritance,
you name it. Locking them all down when a check constraint or function
or view is created seems impractical ... and if we did do it then we'd
get complaints about that too. ("What do you mean I can't change the
setting later?")

In practice I think we have to assume that those variables are set
consistently within any one application. If you go frobbing them
on-the-fly then you're going to have issues.

I suppose paranoid sorts might lobby to make any GUC variable that can
change query semantics be a superuser-only setting, but to me that cure
sounds worse than the disease.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Greg Sabino Mullane 2004-02-18 00:30:58 Re: I want to use postresql for this app, but...
Previous Message Troy Campano 2004-02-17 23:59:07 Re: how to merge a table from another DB