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
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
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. I.e. it
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 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
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 in that
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:
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
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 PK
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. So I
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
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 a noticeable
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 the new
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 excited about
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 wonder what sort
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
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 the
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 have to
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,
[ 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't have a
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 we have done
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
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 BY
and
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 occupying
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:
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
snip
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
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 will
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 idea may not
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 means
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
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. Don't
45 matches
Mail list logo
