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
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.
regards,
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 to make
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
generate PK = PK
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 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 catalogs
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 the
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 =:
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 might
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 semantics
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
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 info for
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. Those
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 the user drop
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
15 matches
Mail list logo
