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://
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
46 matches
Mail list logo