Re: [HACKERS] RI triggers and schemas

2002-04-01 Thread Jan Wieck
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

Re: [HACKERS] RI triggers and schemas

2002-04-01 Thread Tom Lane
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

Re: [HACKERS] RI triggers and schemas

2002-04-01 Thread Stephan Szabo
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...

Re: [HACKERS] RI triggers and schemas

2002-04-01 Thread Tom Lane
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

Re: [HACKERS] RI triggers and schemas

2002-04-01 Thread Tom Lane
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

Re: [HACKERS] RI triggers and schemas

2002-04-01 Thread Tom Lane
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

Re: [HACKERS] RI triggers and schemas

2002-04-01 Thread Stephan Szabo
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

Re: [HACKERS] RI triggers and schemas

2002-03-31 Thread Tom Lane
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

Re: [HACKERS] RI triggers and schemas

2002-03-31 Thread Rod Taylor
. 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

Re: [HACKERS] RI triggers and schemas

2002-03-31 Thread Christopher Kings-Lynne
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

Re: [HACKERS] RI triggers and schemas

2002-03-31 Thread Christopher Kings-Lynne
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

Re: [HACKERS] RI triggers and schemas

2002-03-31 Thread Christopher Kings-Lynne
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

Re: [HACKERS] RI triggers and schemas

2002-03-27 Thread Alex Hayward
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

[HACKERS] RI triggers and schemas

2002-03-26 Thread Tom Lane
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

Re: [HACKERS] RI triggers and schemas

2002-03-26 Thread Jan Wieck
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.

Re: [HACKERS] RI triggers and schemas

2002-03-26 Thread Stephan Szabo
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

Re: [HACKERS] RI triggers and schemas

2002-03-26 Thread Tom Lane
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

Re: [HACKERS] RI triggers and schemas

2002-03-26 Thread Hiroshi Inoue
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.

Re: [HACKERS] RI triggers and schemas

2002-03-26 Thread Tom Lane
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

Re: [HACKERS] RI triggers and schemas

2002-03-26 Thread Christopher Kings-Lynne
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

Re: [HACKERS] RI triggers and schemas

2002-03-26 Thread Stephan Szabo
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

Re: [HACKERS] RI triggers and schemas

2002-03-26 Thread Tom Lane
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