Hi all,
Thank you for helping us to make that patch better.
It didn't
> seem worth blocking this patch for your proposed change (particularly
> since Lætitia seems to have given up on it already).
>
>
I haven't given up. As I said in the begining, Patrick and I were working
together on that patch
I have pushed this.
On 2018-Nov-26, David Fetter wrote:
> On Thu, Nov 22, 2018 at 03:16:11PM +0100, Patrick Francelle wrote:
>
> > 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
On Thu, Nov 22, 2018 at 03:16:11PM +0100, Patrick Francelle wrote:
> 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
>
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
I set this patch waiting-on-author. Please update.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Fabien COELHO writes:
> I've put the patch as "Ready".
I think this could be improved some more. Perhaps something like this
(I've not bothered with markup...)
PostgreSQL does not support CHECK constraints that reference table
data other than the new or updated row being checked. Whi
Thanks for your remarks and advices, and of course for your help to
rewrite the text.
So, it is now included in the new version attached.
I hope it will be ok this time.
At least it looks ok to me.
Patch applies cleanly, doc build ok.
I've put the patch as "Ready".
--
Fabien.
Thanks for your remarks and advices, and of course for your help to
rewrite the text.
So, it is now included in the new version attached.
I hope it will be ok this time.
Patrick Francelle
On 10/30/18 17:14, David G. Johnston wrote:
> The product name, when used in the documentation, is "Postgre
The product name, when used in the documentation, is "PostgreSQL" with
appropriate html elements surrounding it.
Some parts that look or read oddly to me:
"you may expect troubles"
Use - if possible - (commas, not hypens, are customary here)
"does not currently" - drop "currently", it doesn't and
On 08/10/18 07:02, Pantelis Theodosiou wrote:
>
> I like this:
>
>> "Postgres does not currently support CHECK constraints containing
> queries, therefore we recommend to avoid them."
>
> Perhaps adding:
>
>> CHECK constraints are currently meant to be used as *row constraints*
> only.
>> Use -
On August 10, 2018 7:17:09 PM GMT+05:30, Tom Lane wrote:
>Peter Eisentraut writes:
>> I think it would be very easy to restore check constraints separately
>> after all tables in pg_dump. There is already support for that, but
>> it's only used when necessary, for things like not-valid constr
On Fri, Aug 10, 2018 at 09:47:09AM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > I think it would be very easy to restore check constraints separately
> > after all tables in pg_dump. There is already support for that, but
> > it's only used when necessary, for things like not-valid const
On Fri, Aug 10, 2018 at 12:27:49PM +0200, Peter Eisentraut wrote:
> On 09/08/2018 23:32, Alvaro Herrera wrote:
> > I agree that we should point this out in *some* way, just not sure how.
> > Maybe something like "Postgres does not currently support CHECK
> > constraints containing queries, therefor
Peter Eisentraut writes:
> I think it would be very easy to restore check constraints separately
> after all tables in pg_dump. There is already support for that, but
> it's only used when necessary, for things like not-valid constraints.
> The argument in favor of keeping the constraint with the
On 09/08/2018 23:32, Alvaro Herrera wrote:
> I agree that we should point this out in *some* way, just not sure how.
> Maybe something like "Postgres does not currently support CHECK
> constraints containing queries, therefore we recommend to avoid them."
> I would not mention pg_dump by name, just
On Thu, Aug 9, 2018 at 10:32 PM, Alvaro Herrera
wrote:
> On 2018-Aug-07, Lætitia Avrot wrote:
>
> > Hi Peter,
> >
> > I understand what you're pointing at and I agree that it could be a good
> > thing to be able to dump/restore a table without problem.
> >
> > My point was that check constraints
On 2018-Aug-07, Lætitia Avrot wrote:
> Hi Peter,
>
> I understand what you're pointing at and I agree that it could be a good
> thing to be able to dump/restore a table without problem.
>
> My point was that check constraints weren't supposed to be used that way
> theorically (or maybe i'm mista
Hi Peter,
I understand what you're pointing at and I agree that it could be a good
thing to be able to dump/restore a table without problem.
My point was that check constraints weren't supposed to be used that way
theorically (or maybe i'm mistaken ?) so I thought maybe we should just
inform the
Hello Peter,
I'm not sure what is the suggestion wrt to the documentation text. Is the
issue only with the first introductory sentence? Would removing it be
enough?
Yes. But it would be even better to fix pg_dump.
Sure. The purpose of Lætitia patch is simply to document the consequences
i
On 07.07.18 10:23, Fabien COELHO wrote:
> I'm not sure what is the suggestion wrt to the documentation text. Is the
> issue only with the first introductory sentence? Would removing it be
> enough?
Yes. But it would be even better to fix pg_dump.
--
Peter Eisentraut http://www.2n
Hello Peter,
+
+
+ Check constraints are not designed to enforce business rules across
tables.
+ Avoid using check constraints with a function accessing other tables and
+ use instead. Although PostgreSQL won't prevent
you
+ from doing so, beware that dumps generated
On 6/26/18 09:49, Lætitia Avrot wrote:
> +
> +
> + Check constraints are not designed to enforce business rules across
> tables.
> + Avoid using check constraints with a function accessing other tables and
> + use instead. Although PostgreSQL won't
> prevent you
> + from d
On Tue, Jun 26, 2018 at 4:24 AM, Vik Fearing
wrote:
> Looks good to me.
I'll second that. Looks good to me too.
On 26/06/18 09:49, Lætitia Avrot wrote:
> Thanks a lot. I did the modification. It's in the patch enclosed.
Looks good to me.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Hi,
Thanks a lot. I did the modification. It's in the patch enclosed.
Have a nice day,
Lætitia
Le mar. 26 juin 2018 à 01:42, Brad DeJong a écrit :
> On 25/06/18 17:45, Lætitia Avrot wrote:
> > +
> > +
> > + Check constraint are not designed to enforce business rules across
> tables
On 25/06/18 17:45, Lætitia Avrot wrote:
> +
> +
> + Check constraint are not designed to enforce business rules across
tables.
> + Avoid using check constraints with function accessing other tables
and
Subject/verb agreement - either "A check constraint is ..." or "Check
constraint
On 25/06/18 17:45, Lætitia Avrot wrote:
> +
> +
> + Check constraint are not designed to enforce business rules across
> tables.
> + Avoid using check constraints with function accessing other tables and
"with functions" or "with a function". I prefer the former.
> + use ins
Hello,
Ok, I corrected the patch as suggested. I hope I did it right.
Have a nice day,
Lætitia
Le lun. 25 juin 2018 à 16:02, Lætitia Avrot a
écrit :
> Thanks!
> I'll correct the patch ASAP including your modifications.
>
> Le sam. 23 juin 2018 à 19:15, Fabien COELHO a
> écrit :
>
>>
>> Hello
Thanks!
I'll correct the patch ASAP including your modifications.
Le sam. 23 juin 2018 à 19:15, Fabien COELHO a écrit :
>
> Hello lætitia,
>
> My 0.02 € to try to simplify the suggested documentation.
>
> > Check constraint were not
>
> are not
>
> > designed to enforce business rules across tab
Hello lætitia,
My 0.02 € to try to simplify the suggested documentation.
Check constraint were not
are not
designed to enforce business rules across tables.
Avoid using check constraints with function accessing to other tables
accessing other tables (no "to")
and prefer triggers inst
=?UTF-8?Q?L=C3=A6titia_Avrot?= writes:
> ... By looking at the constraint documentation page, we found out there was
> nothing about it. So we decided to write a first version of a patch.
Hi Lætitia! Please add this thread to the open commitfest to make
sure we don't forget abou
t modeling databases books, you'll actually find someting similar.
By looking at the constraint documentation page, we found out there was
nothing about it. So we decided to write a first version of a patch.
You will find it enclosed.
Here are some informations about it :
Project : p
32 matches
Mail list logo
