|From:||Patrick Francelle <patrick(at)francelle(dot)name>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>|
|Cc:||"David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Pantelis Theodosiou <ypercube(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Lætitia Avrot <laetitia(dot)avrot(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Brad DeJong <bpd0018(at)gmail(dot)com>, Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 11/15/18 00:02, Tom Lane wrote:
> I think this could be improved some more. Perhaps something like this
> (I've not bothered with markup...)
> This is a little verbose maybe, but as the text stands, it sounds like
> using a trigger is enough to solve all the consistency problems that
> a cross-row CHECK has. Which it's not of course.
Thank you for the rewriting, this is much more clear and explicit that way.
> I'm also wondering whether it's better to put this in the CREATE TABLE
> reference page instead of here. While there are certainly benefits in
> having the caveat here, I'm a bit troubled by the number of forward
> references to concepts that are described later. OTOH, a lot of people
> who need the warning might never see it if it's buried in the reference
To address your remark, I added a small message in the CREATE TABLE
reference page to be more explicit about the topic, so that it would be
a warning for the users reading the section. And then a reference to the
CHECK constraint page where the full explanation is to be located.
That way, the caveat is mentioned in both pages, but the full
explanation is located only on a single page.
Please, let me know if this is good enough or maybe if I missed
|Next Message||Amit Kapila||2018-11-22 14:18:23||Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query|
|Previous Message||Andrew Dunstan||2018-11-22 13:49:23||Re: reg* checks in pg_upgrade are out of date|