Re: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED
| От | Peter Geoghegan | 
|---|---|
| Тема | Re: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED | 
| Дата | |
| Msg-id | AANLkTinSTCjxunOSfWy4FYmLhLP_7iCHJtMZ20U7desA@mail.gmail.com обсуждение исходный текст  | 
		
| Ответ на | Re: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED (Robert Haas <robertmhaas@gmail.com>) | 
| Ответы | 
                	
            		Re: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED
            		
            		 Re: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED Re: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED  | 
		
| Список | pgsql-hackers | 
On 13 December 2010 16:08, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Dec 13, 2010 at 10:49 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> 2. pg_validate_foreign_key('constraint name');
>> Returns immediately if FK is valid
>> Returns SETOF rows that violate the constraint, or if no rows are
>> returned it updates constraint to show it is now valid.
>> Lock held: AccessShareLock
>
> I'm less sure about this part.  I think there should be a DDL
> statement to validate the foreign key.  The "return the problem" rows
> behavior could be done some other way, or just left to the user to
> write their own query.
+1. I think that a DDL statement is more appropriate, because it makes
the process sort of symmetrical.
Perhaps we could error on the first FK violation found, and give a
"value 'foo' not present in table bar". It ought to not matter that
there could be a lot of violations, because they will be exceptional
if you're using the feature as intended - presumably, you're going to
want to comb through the data to find out exactly what has gone wrong
for each violation. On the off chance that it actually is a problem,
the user can go ahead and write their own query, like Robert
suggested.
--
Regards,
Peter Geoghegan
		
	В списке pgsql-hackers по дате отправления: