Re: Help with restoring a dump in Tar format? (dependencies/ordering)

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Ken Tanzer <ken(dot)tanzer(at)gmail(dot)com>
Cc: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, PG-General Mailing List <pgsql-general(at)postgresql(dot)org>
Subject: Re: Help with restoring a dump in Tar format? (dependencies/ordering)
Date: 2017-06-06 00:32:53
Message-ID: CAKFQuwZnbb4xcbeD=5s+8uh_PQp3LZuosCdA1JLbOazzcFr5cg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Jun 5, 2017 at 5:15 PM, Ken Tanzer <ken(dot)tanzer(at)gmail(dot)com> wrote:

> From the docs:
>> https://www.postgresql.org/docs/9.6/static/sql-createtable.html
>> "Currently, CHECK expressions cannot contain subqueries nor refer to
>> variables other than columns of the current row. The system column tableoid
>> may be referenced, but not any other system column.
>
>
> I wonder if that should say "should not," or be followed by something like
> this:
>
>
Make it say "must not" and I'd agree to change the word "cannot" and leave
the rest. Adding a note regarding functions seems appropriate.

Aside from being a bit more verbose there is nothing useful that writing
this as "CHECK function()" provides that you don't also get by writing
"CREATE TRIGGER". In a green field we'd probably lock down CHECK a bit more
but there is too much code that is technically wrong but correctly
functioning that we don't want to break. IOW, we cannot mandate that the
supplied function be immutable even though we should. And we don't even
enforce immutable execution if a function is defined that way.

​David J.​

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message John R Pierce 2017-06-06 00:40:06 Re: Help with restoring a dump in Tar format? (dependencies/ordering)
Previous Message John R Pierce 2017-06-06 00:28:13 Re: Help with restoring a dump in Tar format? (dependencies/ordering)