Christopher Kings-Lynne wrote:
Yeah, although it'd still be a good idea probably to convert the dump form
to ALTER TABLE in any case. The one downside that was brought up in the
past was the time involved in checking dumped (presumably correct) data
when the constraint is added to very
Jan Wieck [EMAIL PROTECTED] writes:
Christopher Kings-Lynne wrote:
Why can't we just hack up the CREATE CONSTRAINT TRIGGER code to look up
the OIDs, etc. for the arguments and convert them internally to an ALTER
TABLE/ADD CONSTRAINT or whatever...
And what language hack do you
On Mon, 1 Apr 2002, Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
Christopher Kings-Lynne wrote:
Why can't we just hack up the CREATE CONSTRAINT TRIGGER code to look up
the OIDs, etc. for the arguments and convert them internally to an ALTER
TABLE/ADD CONSTRAINT or whatever...
I said:
The table OIDs in pg_trigger would do fine if the trigger function could
get at them, but it can't; so we need to copy them into the trigger
arguments. (Hmm, I suppose another option is to extend the Trigger
data structure to include tgconstrrelid, and just ignore the table names
in
Stephan Szabo [EMAIL PROTECTED] writes:
Sorry, I must have misunderstood you. I thought you were backing away
from changing the arguments that were created for the trigger. Or did
you mean using the stored info on the two oids we already have in the
record (tgrelid and tgconstrrelid)?
No, I
Stephan Szabo [EMAIL PROTECTED] writes:
Well, there is another place where the current name behavior
causes problems so we'd need to be sticking in the fully qualified
name, otherwise creating a table in your search path earlier than
the intended table would break the constraint. This
On Mon, 1 Apr 2002, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
Well, there is another place where the current name behavior
causes problems so we'd need to be sticking in the fully qualified
name, otherwise creating a table in your search path earlier than
the intended
Last week I said:
I think that instead of storing just table names in the trigger
parameters, we should store either table OIDs or schema name + table
name. [ ... ]
So I'm leaning towards OIDs, but wanted to see if anyone had a beef
with that.
I've just realized that if we change the RI
. The
opinions stated above are yours. You cannot imagine why you ever felt
otherwise.
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
To: Stephan Szabo [EMAIL PROTECTED]
Cc: Jan Wieck [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, March 31, 2002 8:43 PM
Subject: Re: [HACKERS] RI
I've just realized that if we change the RI trigger arguments this way,
we will have a really serious problem with accepting pg_dump scripts
from prior versions. The scripts' representation of foreign key
constraints will contain commands like
CREATE CONSTRAINT TRIGGER unnamed AFTER UPDATE
Yeah, although it'd still be a good idea probably to convert the dump form
to ALTER TABLE in any case. The one downside that was brought up in the
past was the time involved in checking dumped (presumably correct) data
when the constraint is added to very large tables. I can probably make
Yeah, although it'd still be a good idea probably to convert the dump form
to ALTER TABLE in any case. The one downside that was brought up in the
past was the time involved in checking dumped (presumably correct) data
when the constraint is added to very large tables. I can probably make
On Tue, 26 Mar 2002, Stephan Szabo wrote:
On Tue, 26 Mar 2002, Jan Wieck wrote:
Tom Lane wrote:
I think the existing scheme of generating the plan during first use
in a particular backend is fine. At least as long as we're sticking
with standard plans at all ... IIRC Stephan was
As of CVS tip, referential integrity triggers are kinda broken: they
will only work for tablenames that are in the current search path.
I think that instead of storing just table names in the trigger
parameters, we should store either table OIDs or schema name + table
name. Do you have any
Tom Lane wrote:
As of CVS tip, referential integrity triggers are kinda broken: they
will only work for tablenames that are in the current search path.
I think that instead of storing just table names in the trigger
parameters, we should store either table OIDs or schema name + table
name.
On Tue, 26 Mar 2002, Tom Lane wrote:
As of CVS tip, referential integrity triggers are kinda broken: they
will only work for tablenames that are in the current search path.
I think that instead of storing just table names in the trigger
parameters, we should store either table OIDs or schema
Jan Wieck [EMAIL PROTECTED] writes:
Actually I'm kicking around a slightly different idea, how to
resolve the entire problem. We could build up the
querystring, required to do the check, at trigger creation
time, parse it and store the querytree node-print or
Tom Lane wrote:
As of CVS tip, referential integrity triggers are kinda broken: they
will only work for tablenames that are in the current search path.
I think that instead of storing just table names in the trigger
parameters, we should store either table OIDs or schema name + table
name.
Hiroshi Inoue [EMAIL PROTECTED] writes:
Tom Lane wrote:
An advantage of using OIDs is that we could forget the pushups that
ALTER TABLE RENAME presently goes through to update RI triggers.
I'm always suspicious about the spec if it makes RENAME easy.
Point taken ;-)
However, unless someone
Tom Lane wrote:
An advantage of using OIDs is that we could forget the pushups that
ALTER TABLE RENAME presently goes through to update RI triggers.
I'm always suspicious about the spec if it makes RENAME easy.
Point taken ;-)
I don't get it???
Chris
On Tue, 26 Mar 2002, Jan Wieck wrote:
Tom Lane wrote:
I think the existing scheme of generating the plan during first use
in a particular backend is fine. At least as long as we're sticking
with standard plans at all ... IIRC Stephan was wondering about
bypassing the whole parse/plan
Stephan Szabo [EMAIL PROTECTED] writes:
The advantage that I see is that we get more control over the time
qualifications used for tuples which may come into play for match
partial. I'm not sure that it's worth the effort to try doing it
this way, but I figured I'd try it.
It might be
22 matches
Mail list logo