Jeff Janes writes:
> I think that pgbench should it make it easy to assess the impact of
> foreign key constraints.
> The attached adds a --foreign-keys option to initialization mode which
> creates all the relevant constraints between the default tables.
I had need of this for testing what I'm
On Sun, May 13, 2012 at 3:03 PM, Peter Geoghegan wrote:
> On 13 May 2012 18:07, Jeff Janes wrote:
>> I think that pgbench should it make it easy to assess the impact of
>> foreign key constraints.
>
> I agree in principle. I favour being more inclusive about pgbench
> options, even if the need f
On 13 May 2012 18:07, Jeff Janes wrote:
> I think that pgbench should it make it easy to assess the impact of
> foreign key constraints.
I agree in principle. I favour being more inclusive about pgbench
options, even if the need for such options is only marginal, which
this isn't - I personally
I think that pgbench should it make it easy to assess the impact of
foreign key constraints.
The attached adds a --foreign-keys option to initialization mode which
creates all the relevant constraints between the default tables.
I changed the order of the table DDLs so that upon reinitialization
>
> On Mon, Oct 25, 2010 at 15:11, Peter Eisentraut wrote:
>
>> Example #4: PK is period, FK is timestamp. FK must be contained in some
>> PK period.
>>
>> CREATE TABLE pk (a period PRIMARY KEY, ...);
>>
>> CREATE TABLE fk (x timestamp REFERENCES pk (a), ...);
>>
>> As above, we can probably arra
On Mon, Oct 25, 2010 at 15:11, Peter Eisentraut wrote:
> Example #4: PK is period, FK is timestamp. FK must be contained in some
> PK period.
>
> CREATE TABLE pk (a period PRIMARY KEY, ...);
>
> CREATE TABLE fk (x timestamp REFERENCES pk (a), ...);
>
> As above, we can probably arrange the opera
On 10/26/10 11:53 AM, Jeff Davis wrote:
> Intuitively, I would expect all 1's to be replaced by 6's in all arrays.
> But I can now see why you would be hesitant to try to support that.
If people want cascading update to work, they shouldn't be denormalizing.
--
On tis, 2010-10-26 at 11:53 -0700, Jeff Davis wrote:
> Case #2 is the strange one, I think. It's not actually just an
> adaptation of #1. #1 requires that all elements of the array have a
> corresponding PK value; but #2 just requires that one of them does.
> Peter, can you clarify case #2? Did you
On Mon, 2010-10-25 at 17:57 -0700, Greg Stark wrote:
> On Mon, Oct 25, 2010 at 5:24 PM, Jeff Davis wrote:
> > I think that's easier when the PK must contain the FK, because then you
> > only need to lock one record. Even when you need to lock multiple
> > records, it seems feasible, and is just an
On Tue, 2010-10-26 at 20:25 +0300, Peter Eisentraut wrote:
> Let's say you have
>
> PK
>
> 1
> 2
> 3
> 4
> 5
>
> FK
>
> [1,2,3]
> [3,4,5]
> [4,4,4]
>
> When you delete PK = 3, what do you expect to happen? OK, you might
> decide to delete the first two rows from the FK table. This might or
On mån, 2010-10-25 at 17:57 -0700, Greg Stark wrote:
> Well if you lock multiple records then it's not clear what operations
> you should conflict with. Removing any one of them wouldn't actually
> invalidate the foreign key reference unless you remove the last one.
>
> I always assumed this was w
On mån, 2010-10-25 at 17:38 -0700, Jeff Davis wrote:
> > Implementing the foreign key side of this merely requires the system
> to
> > have some knowledge of the required "contains" operator, which it
> does
> > in the array case, and something can surely be arranged for the
> range
> > case. The
On mån, 2010-10-25 at 22:10 +0200, Pavel Stehule wrote:
> 2010/10/25 Robert Haas :
> >> Example #1: Foreign key side is an array, every member must match some
> >> PK.
> >>
> >> CREATE TABLE pk (a int PRIMARKY KEY, ...);
> >>
> >> CREATE TABLE fk (x int[] REFERENCES pk (a), ...);
>
> What about op
On Mon, Oct 25, 2010 at 5:24 PM, Jeff Davis wrote:
> I think that's easier when the PK must contain the FK, because then you
> only need to lock one record. Even when you need to lock multiple
> records, it seems feasible, and is just an index lookup, right? Do you
> see a particular problem?
Wel
On Mon, 2010-10-25 at 22:11 +0300, Peter Eisentraut wrote:
> Currently, foreign keys only work with the = operator (the name might be
> different, but it needs to behave like equality). I'm thinking there
> are other scenarios that could be useful, for example with arrays and
> range types.
I agr
On Mon, 2010-10-25 at 12:34 -0700, Greg Stark wrote:
> On Mon, Oct 25, 2010 at 12:11 PM, Peter Eisentraut wrote:
> > Is this sort of thing feasible? Has anyone done more research into the
> > necessary details?
>
> I think the problems arise when you try to figure out what records you
> need to
2010/10/25 Robert Haas :
> On Mon, Oct 25, 2010 at 3:11 PM, Peter Eisentraut wrote:
>> Currently, foreign keys only work with the = operator (the name might be
>> different, but it needs to behave like equality). I'm thinking there
>> are other scenarios that could be useful, for example with arr
On Mon, Oct 25, 2010 at 3:11 PM, Peter Eisentraut wrote:
> Currently, foreign keys only work with the = operator (the name might be
> different, but it needs to behave like equality). I'm thinking there
> are other scenarios that could be useful, for example with arrays and
> range types.
>
> Exa
On Mon, Oct 25, 2010 at 12:11 PM, Peter Eisentraut wrote:
> Is this sort of thing feasible? Has anyone done more research into the
> necessary details?
I think the problems arise when you try to figure out what records you
need to lock to prevent someone from deleting the referenced rows
before
Currently, foreign keys only work with the = operator (the name might be
different, but it needs to behave like equality). I'm thinking there
are other scenarios that could be useful, for example with arrays and
range types.
Example #1: Foreign key side is an array, every member must match some
P
Hi,
How hard/generally useful would it be to allow the target of a foreign
key to be on a set of columns where only a subset of them actually have
a unique constraint. For example:
CREATE TABLE base (
id INTEGER NOT NULL PRIMARY KEY,
type INTEGER NOT NULL
);
CREATE TABLE type1in
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Mon, 12 Feb 2007, Tom Lane wrote:
>> It turns out this isn't sufficient: ri_Check_Pk_Match() wants to
>> generate PK = PK checks, and the PK = FK operator isn't the right one
>> for that.
> Ugh, right, for modifications of the pk side with no action t
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> As far as I understood the proposal, tgargs wouldn't go away, it would
> just not be populated for RI triggers.
Yes, of course. I wasn't suggesting that we take away the ability to
pass arguments to triggers in general.
reg
Robert Treat wrote:
On Saturday 10 February 2007 13:59, Tom Lane wrote:
Stephan Szabo <[EMAIL PROTECTED]> writes:
I'd say we probably want to keep the tgargs info for at least a version
or two after changing the implementation. Getting rid of using the args
info sounds like a good idea.
We wh
On Saturday 10 February 2007 13:59, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > I'd say we probably want to keep the tgargs info for at least a version
> > or two after changing the implementation. Getting rid of using the args
> > info sounds like a good idea.
>
> We whack the
Stephan Szabo <[EMAIL PROTECTED]> writes:
> I think #1, while ugly, is probably less ugly than the others, although I
> guess it means even more work if the underlying type of the column is
> changed.
Oy, I hadn't thought of that. [ considers... ] I *think* that it'll
work without special code,
On Mon, 12 Feb 2007, Tom Lane wrote:
> I wrote:
> >> * Add an oid[] column to pg_constraint that stores the equality operator
> >> OIDs for a foreign-key constraint, in the same column order as conkey[]
> >> and confkey[].
>
> It turns out this isn't sufficient: ri_Check_Pk_Match() wants to
> gene
I wrote:
>> * Add an oid[] column to pg_constraint that stores the equality operator
>> OIDs for a foreign-key constraint, in the same column order as conkey[]
>> and confkey[].
It turns out this isn't sufficient: ri_Check_Pk_Match() wants to
generate PK = PK checks, and the PK = FK operator isn't
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> key constraints loaded from dumps from pre-7.3 databases will no longer
>> work. Those dumps just contain "CREATE CONSTRAINT TRIGGER" commands
>> which will not provide enough information. We can make the triggers
>> throw errors suggesting that th
> After digging around in the code for awhile I realized that there's a
> potentially bigger backwards-compatibility issue here: if we make the
> RI triggers dependent on finding a pg_constraint entry, then foreign
> key constraints loaded from dumps from pre-7.3 databases will no longer
> work. T
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Fri, 9 Feb 2007, Tom Lane wrote:
>> I am pretty strongly tempted to stop storing anything in tgargs for RI
>> triggers --- it's ugly, and updating the info during RENAME commands
>> is a pain in the rear.
> I'd say we probably want to keep the tgargs
Stephan Szabo <[EMAIL PROTECTED]> writes:
> The reason I was wondering is that it uses tgnargs == 4 as the check, and
> if we change the meanings of tgnargs, we'd need to change the check.
Sure, it'd be looking for a zero-length conkeys array instead.
regards, tom lane
--
On Sat, 10 Feb 2007, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > One side question is what should we do about the
> > places in the current system where it checks for the key sets being empty?
>
> I don't see that this affects that either way. I can't quite imagine
> what the
Stephan Szabo <[EMAIL PROTECTED]> writes:
> I assume you're speaking of the version where we just change the
> constraints to use statements with the OPERATOR() syntax and potential
> casts rather than the discussion at the end about changing the pk checks
> to avoid planning entirely?
Yeah, we mi
On Fri, 9 Feb 2007, Tom Lane wrote:
> Almost a year ago, we talked about the problem that referential
> integrity should be selecting comparison operators on the basis
> of b-tree index opclasses, instead of assuming that the appropriate
> operator is always named "=":
> http://archives.postgresq
Almost a year ago, we talked about the problem that referential
integrity should be selecting comparison operators on the basis
of b-tree index opclasses, instead of assuming that the appropriate
operator is always named "=":
http://archives.postgresql.org/pgsql-hackers/2006-02/msg00960.php
http://
On Sun, Sep 10, 2006 at 09:40:51AM -0700, Joshua D. Drake wrote:
>
> >In any case the same logic that leads to it being desirable to report all
> >the
> >errors to the user in a UI and not just report them one by one also
> >applies to
> >the database. I'm not sure it's the most important issue
Joshua D. Drake wrote:
>
> >In any case the same logic that leads to it being desirable to report all
> >the
> >errors to the user in a UI and not just report them one by one also
> >applies to
> >the database. I'm not sure it's the most important issue in the world, but
> >it
> >does seem like
On Sun, 10 Sep 2006, Gregory Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Stephan Szabo <[EMAIL PROTECTED]> writes:
> > > I think if we were going to do this that all the constraint violations for
> > > unique, not null, check and foreign keys should be handled similarly, so
> > > we'
In any case the same logic that leads to it being desirable to report all the
errors to the user in a UI and not just report them one by one also applies to
the database. I'm not sure it's the most important issue in the world, but it
does seem like a "it would be nice" feature if it reported al
Tom Lane <[EMAIL PROTECTED]> writes:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > I think if we were going to do this that all the constraint violations for
> > unique, not null, check and foreign keys should be handled similarly, so
> > we'd probably want something more general than just a way
Stephan Szabo <[EMAIL PROTECTED]> writes:
> I think if we were going to do this that all the constraint violations for
> unique, not null, check and foreign keys should be handled similarly, so
> we'd probably want something more general than just a way for the ri
> triggers to do this. I don't hav
On Sun, 10 Sep 2006, Gregory Stark wrote:
> Chris Mair <[EMAIL PROTECTED]> writes:
>
> > What's the purpose of letting you insert 1000 records, then, at the end
> > say: "hah, all is rolled back becauase the 2nd record was invalid".
> > PG justly throws the exception immediately to let you know it
Chris Mair <[EMAIL PROTECTED]> writes:
> What's the purpose of letting you insert 1000 records, then, at the end
> say: "hah, all is rolled back becauase the 2nd record was invalid".
> PG justly throws the exception immediately to let you know it's futile
> inserting 998 more records.
Well there'
MAR - Secretariado Geral wrote:
> Hi everybody,
>
> First of all i'de like to apolagize cause my poor english. After this, i
> shuould say that i beleavee a year ago i brought this problem to the
> community but i donn't remember some answering about it. The problem is:
>
> Every time a users m
> First of all i'de like to apolagize cause my poor english. After this,
> i shuould say that i beleavee a year ago i brought this problem to the
> community but i donn't remember some answering about it. The problem
> is:
>
> Every time a users misses a external refrenced key the PGSql raises
Hi everybody,
First of all i'de like to apolagize cause my poor
english. After this, i shuould say that i
beleavee a year ago i brought this problem to the community but i donn't
remember some answering about it. The problem is:
Every time a users misses a external refrenced key
the PGSq
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> Just to check, are you referring to constraint triggers here?
No, I don't wish to remove constraint triggers. I would like to see
them become a better-documented, better-supported feature, which might
require some changes ... I don't recall why we
Tom Lane writes:
"Michael Paesold" <[EMAIL PROTECTED]> writes:
Will this trigger still be called, so it can abort the delete?
We'd certainly still call triggers and check row-level constraints,
and any error would abort the whole statement (leaving A unmodified).
The case that I think we'd
"Michael Paesold" <[EMAIL PROTECTED]> writes:
> B (id) references A (id), with ON DELETE CASCADE
> Usually deleting a row from A will cause all referencing rows in B to be
> deleted, too. Nevertheless B has a BEFORE DELETE trigger "check_delete" that
> checks if a row of B may be deleted or not.
Tom Lane wrote:
If we did this then RI checks would no longer be subvertible by rules
or user triggers.
Stephan Szabo writes:
I don't think that it'd really help because it's the actions that are
generally subvertible not the checks and since those are looking at the
potentially not indexed fk
On Mar 4, 2006, at 9:22 , Tom Lane wrote:
If we did this then RI checks would no longer be subvertible by
rules or
user triggers. Although I've been heard to argue that that's a
feature,
I think the majority of people feel it's a bug, and wouldn't be
sorry to
see it go.
Just to check,
On Fri, 3 Mar 2006, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On Fri, 3 Mar 2006, Tom Lane wrote:
> >> BTW, I had another thought about this: if we go this way, then the plans
> >> associated with RI check queries would essentially always be trivial
> >> index lookups (for ev
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Fri, 3 Mar 2006, Tom Lane wrote:
>> BTW, I had another thought about this: if we go this way, then the plans
>> associated with RI check queries would essentially always be trivial
>> index lookups (for everything except RI_Initial_Check).
> Would we
On Fri, 3 Mar 2006, Tom Lane wrote:
> BTW, I had another thought about this: if we go this way, then the plans
> associated with RI check queries would essentially always be trivial
> index lookups (for everything except RI_Initial_Check). It'd be within
> the realm of feasibility to throw away
BTW, I had another thought about this: if we go this way, then the plans
associated with RI check queries would essentially always be trivial
index lookups (for everything except RI_Initial_Check). It'd be within
the realm of feasibility to throw away the current cached-plan RI
infrastructure and
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> Andrew Dunstan wrote:
>>> Speaking of parsers, did anyone else notice that gcc in its latest
>>> release has ripped out the bison based parser for C and Objective-C in
>>> favor of a hand cut RD parser?
>>
>> Yeah, I did. I w
On Thu, Mar 02, 2006 at 08:41:20PM -0500, Tom Lane wrote:
> elein <[EMAIL PROTECTED]> writes:
> > ... What I'm saying is that the opclass needs to be
> > an option to PRIMARY KEY and FOREIGN KEY--
>
> PRIMARY KEY and UNIQUE, you mean.
>
> This was brought up before, but I remain less than excite
Alvaro Herrera wrote:
> Andrew Dunstan wrote:
> > Speaking of parsers, did anyone else notice that gcc in its latest
> > release has ripped out the bison based parser for C and Objective-C in
> > favor of a hand cut RD parser?
>
> Yeah, I did. I wonder what sort of effort they went to write th
Andrew Dunstan wrote:
> Stephan Szabo wrote:
>
> >On Fri, 3 Mar 2006, Tom Lane wrote:
> >
> >>The reason I'm hesitant to add a bunch more cross-type operators is
> >>mainly that we have too darn many operators named "=" already. I've
> >>seen in recent profiling tests that it's taking the parser
Stephan Szabo wrote:
On Fri, 3 Mar 2006, Tom Lane wrote:
The reason I'm hesitant to add a bunch more cross-type operators is
mainly that we have too darn many operators named "=" already. I've
seen in recent profiling tests that it's taking the parser a noticeable
amount of time to decide
On Fri, 3 Mar 2006, Tom Lane wrote:
> The reason I'm hesitant to add a bunch more cross-type operators is
> mainly that we have too darn many operators named "=" already. I've
> seen in recent profiling tests that it's taking the parser a noticeable
> amount of time to decide which one is meant.
Stephan Szabo <[EMAIL PROTECTED]> writes:
> I'd argue that this case makes sense in a purely theoretical sense,
> numeric(8,0) references int is a sensible operation (when you don't take
> into account specific PostgreSQL limitations) and it's required by spec,
> but I agree that promotion on the P
On Fri, 3 Mar 2006, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > There's a bit of difference between not encouraging it and disallowing it
> > entirely, but I'm willing to buy that argument. I do think that numeric
> > reference int needs to be allowed though, and I thought th
Stephan Szabo <[EMAIL PROTECTED]> writes:
> There's a bit of difference between not encouraging it and disallowing it
> entirely, but I'm willing to buy that argument. I do think that numeric
> reference int needs to be allowed though, and I thought that's also
> currently not there (although int
On Fri, 3 Mar 2006, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On Thu, 2 Mar 2006, Tom Lane wrote:
> >> 1. If the index opclass contains an exact operator for the case
> >> "PKtype = FKtype", use that operator.
>
> > Is this rule to read explicitly naming '=' or just the item
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Thu, 2 Mar 2006, Tom Lane wrote:
>> 1. If the index opclass contains an exact operator for the case
>> "PKtype = FKtype", use that operator.
> Is this rule to read explicitly naming '=' or just the item in that
> position in the opclass?
The operator
On Thu, 2 Mar 2006, Tom Lane wrote:
> [ returning to a week-old thread... ]
>
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On Thu, 23 Feb 2006, Tom Lane wrote:
> >> Any thoughts about details? My feeling is that we should tie RI
> >> semantics to btree opclasses, same as we have done for ORDER
elein <[EMAIL PROTECTED]> writes:
> ... What I'm saying is that the opclass needs to be
> an option to PRIMARY KEY and FOREIGN KEY--
PRIMARY KEY and UNIQUE, you mean.
This was brought up before, but I remain less than excited about it.
You can get essentially the same functionality by doing a CR
On Thu, Mar 02, 2006 at 08:05:59PM -0500, Tom Lane wrote:
> [ returning to a week-old thread... ]
>
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On Thu, 23 Feb 2006, Tom Lane wrote:
> >> Any thoughts about details? My feeling is that we should tie RI
> >> semantics to btree opclasses, same as
[ returning to a week-old thread... ]
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Thu, 23 Feb 2006, Tom Lane wrote:
>> Any thoughts about details? My feeling is that we should tie RI
>> semantics to btree opclasses, same as we have done for ORDER BY
>> and some other SQL constructs, but I don'
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Incidentally, shouldn't the existing RI queries (eg. SELECT ... FOR
> SHARE) explicity specify operator(pg_catalog.=)?
Then they'd be guaranteed to fail for datatypes/operators created in
other schemas, rather than only at risk of failing. Do
No, there's no need for that. It means that the RI stuff would have to
take whatever steps we agree on to determine the exact comparison
operator to use, and then be sure to emit SQL that will select exactly
that operator --- this involves using the OPERATOR(foo.=) syntax to
remove schema-ambigui
Tom Lane wrote:
> Any thoughts about details? My feeling is that we should tie RI
> semantics to btree opclasses, same as we have done for ORDER BY
> and some other SQL constructs, but I don't have a concrete proposal
> right offhand. The btree idea may not cover cross-type FKs anyway.
This mea
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Any thoughts about details? My feeling is that we should tie RI
>> semantics to btree opclasses, same as we have done for ORDER BY
>> and some other SQL constructs, but I don't have a concrete proposal
>> right offhand. The btree ide
On Thu, 23 Feb 2006, Tom Lane wrote:
> I looked into the problem reported here:
> http://archives.postgresql.org/pgsql-admin/2006-02/msg00261.php
> To wit, a pg_restore of a foreign key constraint involving user-defined
> types produces
>
> pg_restore: WARNING: foreign key constraint "luuid_fkey"
On Thu, Feb 23, 2006 at 01:10:07PM -0500, Tom Lane wrote:
> I looked into the problem reported here:
> http://archives.postgresql.org/pgsql-admin/2006-02/msg00261.php
> This has been a hazard in the RI code since day one, of course, but
> I think it's time to face up to it and do something about
I looked into the problem reported here:
http://archives.postgresql.org/pgsql-admin/2006-02/msg00261.php
To wit, a pg_restore of a foreign key constraint involving user-defined
types produces
pg_restore: WARNING: foreign key constraint "luuid_fkey" will require costly
sequential scans
DETAIL: K
Neil Conway <[EMAIL PROTECTED]> writes:
>> (b) it can share infrastructure with the other RI triggers.
> Such as? I don't see anything it allows us to share.
Note the ri_BuildQueryKeyFull call, and the arguments thereto.
As to the notational convenience issue, I think it's good that
RI_FKey_keye
Tom Lane wrote:
Because (a) it needs all the same arguments
Well, it needs the Trigger that we're in the process of queueing, the
old tuple, the new tuple, and the updated relation. It doesn't need the
rest of the content of TriggerData. trigger.c has to manually construct
a TriggerData to p
Neil Conway <[EMAIL PROTECTED]> writes:
> Speaking of which, does anyone see a reason why RI_FKey_keyequal_upd()
> is implemented as a pseudo-trigger function -- e.g. taking a pointer to
> a TriggerData?
Because (a) it needs all the same arguments and (b) it can share
infrastructure with the oth
Tom Lane wrote:
But the check could incorporate the same transaction ID test already
in use. I think Neil is right that it'd be a win to apply the test
before enqueueing the trigger instead of after.
Speaking of which, does anyone see a reason why RI_FKey_keyequal_upd()
is implemented as a ps
On Thu, 26 May 2005, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On Thu, 26 May 2005, Tom Lane wrote:
> >> The thoughts I've had about special-casing RI events to save memory
> >> have to do with the idea of lossy storage.
>
> > One problem with that is that it works for the c
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Thu, 26 May 2005, Tom Lane wrote:
>> The thoughts I've had about special-casing RI events to save memory
>> have to do with the idea of lossy storage.
> One problem with that is that it works for the constraint check but not
> for referential actions,
On Thu, 26 May 2005, Tom Lane wrote:
> The thoughts I've had about special-casing RI events to save memory
> have to do with the idea of lossy storage. As you accumulate more
> per-row events, at some point it becomes more efficient to forget
> the individual rows and just reapply the original fu
On Thu, 26 May 2005, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> >> Okay, I can't think of cases even with triggers and the like where
> >> removing the check on equal valued rows would give appreciably different
> >> results, but I haven't thought too hard about it.
>
> > Err,
Stephan Szabo <[EMAIL PROTECTED]> writes:
>> Okay, I can't think of cases even with triggers and the like where
>> removing the check on equal valued rows would give appreciably different
>> results, but I haven't thought too hard about it.
> Err, except the case that Tom mentions in his message.
On Thu, 26 May 2005, Stephan Szabo wrote:
> On Fri, 27 May 2005, Neil Conway wrote:
>
> > Stephan Szabo wrote:
> > > Are you sure? RI_FKey_Check seems to have a section on
> > > TRIGGER_FIRED_BY_UPDATE which seems to check if the keys are equal if the
> > > old row wasn't part of this transaction
On Fri, 27 May 2005, Neil Conway wrote:
> Stephan Szabo wrote:
> > Are you sure? RI_FKey_Check seems to have a section on
> > TRIGGER_FIRED_BY_UPDATE which seems to check if the keys are equal if the
> > old row wasn't part of this transaction.
>
> Well, regardless of how RI_FKey_Check() itself wo
Stephan Szabo <[EMAIL PROTECTED]> writes:
> Are you sure? RI_FKey_Check seems to have a section on
> TRIGGER_FIRED_BY_UPDATE which seems to check if the keys are equal if the
> old row wasn't part of this transaction. I'm not sure why it's doing the
> transaction id check, but it looks like it wil
On Thu, 26 May 2005, Stephan Szabo wrote:
> On Thu, 26 May 2005, Neil Conway wrote:
>
> > (2) For per-row RI triggers of all kinds, we save the trigger under
> > CurTransactionContext and invoke it at the end of the current query.
> > There is not even overflow to disk (the report that prompted me
Stephan Szabo wrote:
Are you sure? RI_FKey_Check seems to have a section on
TRIGGER_FIRED_BY_UPDATE which seems to check if the keys are equal if the
old row wasn't part of this transaction.
Well, regardless of how RI_FKey_Check() itself works, ISTM there is no
need to enqueue the RI trigger i
On Thu, 26 May 2005, Neil Conway wrote:
> I spent a little while looking into a performance issue with a large
> UPDATE on a table with foreign keys. A few questions:
>
> (1) When a PK table is updated, we skip firing the per-row UPDATE RI
> triggers if none of the referenced columns in the PK tab
I spent a little while looking into a performance issue with a large
UPDATE on a table with foreign keys. A few questions:
(1) When a PK table is updated, we skip firing the per-row UPDATE RI
triggers if none of the referenced columns in the PK table have been
modified. However, AFAICS we do n
Stephan Szabo <[EMAIL PROTECTED]> writes:
>> If not, is this a TODO perhaps?
> Maybe. It's been discussed before IIRC. Doing the referential actions
> might get tricky, and you'd often want to index so that finding the
> individual array elements isn't expensive.
Checking PK deletions efficientl
On Wed, 20 Apr 2005, Christopher Kings-Lynne wrote:
> Hi,
>
> Can you put a foreign key constraint on an array column that says that
> each element of the array must match a primary key?
Not currently, because foreign keys are between directly comparable
things.
> If not, is this a TODO perhaps?
> Hi,
>
> Can you put a foreign key constraint on an array column that says that
> each element of the array must match a primary key?
>
> If not, is this a TODO perhaps?
>
> Chris
>
Hello,
Using array values for foreign key is very special. I not sure, so all
people need it. More interest
Hi,
Can you put a foreign key constraint on an array column that says that
each element of the array must match a primary key?
If not, is this a TODO perhaps?
Chris
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
ht
Hi,
I am using postgresql for a system, and having a lot of deadlocks due to
foreign keys. I am aware of the situation regarding this from browsing
the mailing list archives.
As I understand it the solution is to implement dirty reads and modify
the referential integrity triggers to use these ins
On Fri, 2002-09-06 at 01:19, Christopher Kings-Lynne wrote:
> OK,
>
> The argument about using ALTER TABLE/ADD FOREIGN KEY in dumps was that it
> caused an actual check of the data in the table, right? This was going to
> be much slower than using CREATE CONSTRAINT TRIGGER.
>
> So, why can't we
1 - 100 of 105 matches
Mail list logo
