On Tue, Mar 24, 2015 at 4:28 PM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
>
>
> On Mon, Mar 23, 2015 at 12:33 PM, Tom Lane wrote:
> >
> > =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?=
writes:
> > > On Fri, Mar 20, 2015 at 4:37 PM, Tom Lane wrote:
> > We could fix it by, say, h
On Mon, Mar 23, 2015 at 12:33 PM, Tom Lane wrote:
>
> =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
> > On Fri, Mar 20, 2015 at 4:37 PM, Tom Lane wrote:
> We could fix it by, say, having CheckConstraintFetch() sort the
> constraints by name after loading them.
>
> > Isn't better do
On 24 March 2015 at 17:51, Ashutosh Bapat
wrote:
>
> In case of million inserts or bulk load with constraints on, these few
> cycles spent in ordering the constraints might be problematic, unless the
> ordering happens only once for a series of inserts.
>
As far as I can see this sort only occu
On Mon, Mar 23, 2015 at 7:46 PM, Tom Lane wrote:
> Ashutosh Bapat writes:
> > I might be only one objecting here but ...
> > On Sat, Mar 21, 2015 at 12:45 AM, Tom Lane wrote:
> >> My Salesforce colleagues noticed some tests flapping as a result of
> table
> >> CHECK constraints not always being
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
> On Fri, Mar 20, 2015 at 4:37 PM, Tom Lane wrote:
We could fix it by, say, having CheckConstraintFetch() sort the
constraints by name after loading them.
> Isn't better do this to read pg_constraint in name order?
> - conscan = systa
On Fri, Mar 20, 2015 at 4:37 PM, Tom Lane wrote:
>
> =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
> > On Fri, Mar 20, 2015 at 4:19 PM, Peter Geoghegan wrote:
> >> On Fri, Mar 20, 2015 at 12:15 PM, Tom Lane wrote:
> >>> We could fix it by, say, having CheckConstraintFetch() sort the
> >>> co
Ashutosh Bapat writes:
> I might be only one objecting here but ...
> On Sat, Mar 21, 2015 at 12:45 AM, Tom Lane wrote:
>> My Salesforce colleagues noticed some tests flapping as a result of table
>> CHECK constraints not always being enforced in the same order; ie, if a
>> tuple insertion/update
I might be only one objecting here but ...
On Sat, Mar 21, 2015 at 12:45 AM, Tom Lane wrote:
> My Salesforce colleagues noticed some tests flapping as a result of table
> CHECK constraints not always being enforced in the same order; ie, if a
> tuple insertion/update violates more than one CHECK
On Sunday, March 22, 2015, David Steele wrote:
> On 3/20/15 3:37 PM, Tom Lane wrote:
> > =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= > writes:
> >> On Fri, Mar 20, 2015 at 4:19 PM, Peter Geoghegan > wrote:
> >>> On Fri, Mar 20, 2015 at 12:15 PM, Tom Lane > wrote:
> We could fix it by, say, h
On 3/20/15 3:37 PM, Tom Lane wrote:
> =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
>> On Fri, Mar 20, 2015 at 4:19 PM, Peter Geoghegan wrote:
>>> On Fri, Mar 20, 2015 at 12:15 PM, Tom Lane wrote:
We could fix it by, say, having CheckConstraintFetch() sort the
constraints by name af
On 21/03/15 08:15, Tom Lane wrote:
My Salesforce colleagues noticed some tests flapping as a result of table
CHECK constraints not always being enforced in the same order; ie, if a
tuple insertion/update violates more than one CHECK constraint, it's not
deterministic which one is reported. This
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
> On Fri, Mar 20, 2015 at 4:19 PM, Peter Geoghegan wrote:
>> On Fri, Mar 20, 2015 at 12:15 PM, Tom Lane wrote:
>>> We could fix it by, say, having CheckConstraintFetch() sort the
>>> constraints by name after loading them.
>> What not by OID, as
On Fri, Mar 20, 2015 at 4:19 PM, Peter Geoghegan wrote:
>
> On Fri, Mar 20, 2015 at 12:15 PM, Tom Lane wrote:
> > We could fix it by, say, having CheckConstraintFetch() sort the
> > constraints by name after loading them.
>
>
> What not by OID, as with indexes? Are you suggesting that this would
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> My Salesforce colleagues noticed some tests flapping as a result of table
> CHECK constraints not always being enforced in the same order; ie, if a
> tuple insertion/update violates more than one CHECK constraint, it's not
> deterministic which one is report
On Fri, Mar 20, 2015 at 12:15 PM, Tom Lane wrote:
> We could fix it by, say, having CheckConstraintFetch() sort the
> constraints by name after loading them.
What not by OID, as with indexes? Are you suggesting that this would
become documented behavior?
--
Peter Geoghegan
--
Sent via pgsql
My Salesforce colleagues noticed some tests flapping as a result of table
CHECK constraints not always being enforced in the same order; ie, if a
tuple insertion/update violates more than one CHECK constraint, it's not
deterministic which one is reported. This is evidently because
relcache.c's Che
16 matches
Mail list logo
