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() has
Magnus Hagander mag...@hagander.net 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
On Wed, Jun 30, 2010 at 16:38, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net 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.
Magnus Hagander mag...@hagander.net writes:
On Wed, Jun 30, 2010 at 16:38, Tom Lane t...@sss.pgh.pa.us 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?
On Wed, Jun 30, 2010 at 11:02 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Wed, Jun 30, 2010 at 16:38, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com 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
On Wed, Jun 30, 2010 at 11:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On 30/06/10 17:11, Robert Haas wrote:
On Wed, Jun 30, 2010 at 11:49 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haasrobertmh...@gmail.com writes:
My scintillating contribution to this discussion is the observation
that unrestorable dumps suck.
No doubt, but is this a real problem in
Robert Haas robertmh...@gmail.com writes:
On Wed, Jun 30, 2010 at 11:49 AM, Tom Lane t...@sss.pgh.pa.us 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
On 30/06/10 18:11, Magnus Hagander wrote:
On Wed, Jun 30, 2010 at 18:33, Richard Huxtond...@archonet.com 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
On Wed, Jun 30, 2010 at 18:33, Richard Huxton d...@archonet.com wrote:
On 30/06/10 17:11, Robert Haas wrote:
On Wed, Jun 30, 2010 at 11:49 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haasrobertmh...@gmail.com writes:
My scintillating contribution to this discussion is the observation
On Wed, Jun 30, 2010 at 19:16, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Jun 30, 2010 at 11:49 AM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Jun 30, 2010 at 9:47 AM, Magnus Hagander mag...@hagander.net 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
Magnus Hagander mag...@hagander.net writes:
On Wed, Jun 30, 2010 at 19:16, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Jun 30, 2010 at 20:13, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Wed, Jun 30, 2010 at 19:16, Tom Lane t...@sss.pgh.pa.us wrote:
I concur with the thought that the most useful solution might be a way
to tell pg_restore to remove or disable check
On ons, 2010-06-30 at 10:38 -0400, Tom Lane wrote:
Magnus Hagander mag...@hagander.net 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.
kibo
The search
Peter Eisentraut pete...@gmx.net writes:
kibo
The search condition shall simply contain a boolean value
expression that is retrospectively deterministic.
This is then defined in a rather complex manner that ends up disallowing
col now() but allowing col now().
/kibo
Oh, cute. Seems to
On Wed, Jun 30, 2010 at 6:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
kibo
The search condition shall simply contain a boolean value
expression that is retrospectively deterministic.
This is then defined in a rather complex manner that ends up
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 longer
Robert Haas robertmh...@gmail.com writes:
On Wed, Jun 30, 2010 at 6:57 PM, Tom Lane t...@sss.pgh.pa.us 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
20 matches
Mail list logo
