Robert Haas writes:
> On Wed, Jun 30, 2010 at 6:57 PM, Tom Lane wrote:
>> The detailed definition is amazingly laborious and yet limited, though,
>> as it basically doesn't address the problem except for that specific
>> case and close relatives.
> Well, solving the problem in general is equival
mag...@hagander.net (Magnus Hagander) writes:
>> I concur with the thought that the most useful solution might be a way
>> to tell pg_restore to remove or disable check constraints.
>
> Uh, say what? Are you saying pg_restore should actually remove
> something from the database schema? And thus no
On Wed, Jun 30, 2010 at 6:57 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>>
>> "The shall simply contain a > expression> that is retrospectively deterministic."
>
>> This is then defined in a rather complex manner that ends up disallowing
>> col > now() but allowing col < now().
>>
>
> Oh,
Peter Eisentraut writes:
>
> "The shall simply contain a expression> that is retrospectively deterministic."
> This is then defined in a rather complex manner that ends up disallowing
> col > now() but allowing col < now().
>
Oh, cute. Seems to have been added in SQL:2003. I guess somebody
On ons, 2010-06-30 at 10:38 -0400, Tom Lane wrote:
> Magnus Hagander writes:
> > Shouldn't we disallow anything that's not IMMUTABLE in a check constraint?
>
> I think you'd get too many howls of pain ... also, such a restriction is
> likely contrary to SQL spec.
"The shall simply contain a t
On Wed, Jun 30, 2010 at 20:13, Tom Lane wrote:
> Magnus Hagander writes:
>> On Wed, Jun 30, 2010 at 19:16, Tom Lane wrote:
>>> I concur with the thought that the most useful solution might be a way
>>> to tell pg_restore to remove or disable check constraints.
>
>> Uh, say what? Are you saying p
Magnus Hagander writes:
> On Wed, Jun 30, 2010 at 19:16, Tom Lane wrote:
>> I concur with the thought that the most useful solution might be a way
>> to tell pg_restore to remove or disable check constraints.
> Uh, say what? Are you saying pg_restore should actually remove
> something from the d
On Wed, Jun 30, 2010 at 9:47 AM, Magnus Hagander wrote:
> We currently allow this:
>
> postgres=# create table t(a timestamptz not null primary key, check(a >
> now()));
> NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
> "t_pkey" for table "t"
> CREATE TABLE
>
>
> Which seems very
On Wed, Jun 30, 2010 at 19:16, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jun 30, 2010 at 11:49 AM, Tom Lane wrote:
>>> I can't recall many
>>> field complaints about it. And the ones I do recall wouldn't have been
>>> prevented by a check as stupid as "are there immutable functions in
>>
On Wed, Jun 30, 2010 at 18:33, Richard Huxton wrote:
> On 30/06/10 17:11, Robert Haas wrote:
>>
>> On Wed, Jun 30, 2010 at 11:49 AM, Tom Lane wrote:
>>>
>>> Robert Haas writes:
My scintillating contribution to this discussion is the observation
that unrestorable dumps suck.
>>>
>>
On 30/06/10 18:11, Magnus Hagander wrote:
On Wed, Jun 30, 2010 at 18:33, Richard Huxton wrote:
IMHO The real solution would be something that could strip/rewrite the
constraint on restore rather than trying to prevent people being stupid
though. People *will* just tag their functions as immuta
Robert Haas writes:
> On Wed, Jun 30, 2010 at 11:49 AM, Tom Lane wrote:
>> I can't recall many
>> field complaints about it. And the ones I do recall wouldn't have been
>> prevented by a check as stupid as "are there immutable functions in
>> here".
> Hopefully there aren't too many ways to get
On 30/06/10 17:11, Robert Haas wrote:
On Wed, Jun 30, 2010 at 11:49 AM, Tom Lane wrote:
Robert Haas writes:
My scintillating contribution to this discussion is the observation
that unrestorable dumps suck.
No doubt, but is this a real problem in practice?
Magnus tells me that that was wha
On Wed, Jun 30, 2010 at 11:49 AM, Tom Lane wrote:
> Robert Haas writes:
>> My scintillating contribution to this discussion is the observation
>> that unrestorable dumps suck.
>
> No doubt, but is this a real problem in practice?
Magnus tells me that that was what prompted his original email.
>
Robert Haas writes:
> My scintillating contribution to this discussion is the observation
> that unrestorable dumps suck.
No doubt, but is this a real problem in practice? I can't recall many
field complaints about it. And the ones I do recall wouldn't have been
prevented by a check as stupid a
On Wed, Jun 30, 2010 at 11:02 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Wed, Jun 30, 2010 at 16:38, Tom Lane wrote:
>>> The example seems to me to be in the category of "so don't do that"
>>> rather than something that we need to save users from. Yes, it's
>
>> In that case, should we
Magnus Hagander writes:
> On Wed, Jun 30, 2010 at 16:38, Tom Lane wrote:
>> The example seems to me to be in the category of "so don't do that"
>> rather than something that we need to save users from. Yes, it's
> In that case, should we at least throw a warning?
I don't see a reason to do tha
On Wed, Jun 30, 2010 at 16:38, Tom Lane wrote:
> Magnus Hagander writes:
>> Shouldn't we disallow anything that's not IMMUTABLE in a check constraint?
>
> I think you'd get too many howls of pain ... also, such a restriction is
> likely contrary to SQL spec.
Really? That sounds strange, but I ca
Magnus Hagander writes:
> Shouldn't we disallow anything that's not IMMUTABLE in a check constraint?
I think you'd get too many howls of pain ... also, such a restriction is
likely contrary to SQL spec.
The example seems to me to be in the category of "so don't do that"
rather than something tha
We currently allow this:
postgres=# create table t(a timestamptz not null primary key, check(a > now()));
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
"t_pkey" for table "t"
CREATE TABLE
Which seems very wrong. For one thing, a dump of this database can not
be restored if now()
20 matches
Mail list logo
