Re: Why does an ON SELECT rule have to be named "_RETURN"?
От | Tom Lane |
---|---|
Тема | Re: Why does an ON SELECT rule have to be named "_RETURN"? |
Дата | |
Msg-id | 28448.1140104476@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Why does an ON SELECT rule have to be named "_RETURN"? (Martijn van Oosterhout <kleptog@svana.org>) |
Ответы |
Re: Why does an ON SELECT rule have to be named "_RETURN"?
|
Список | pgsql-general |
Martijn van Oosterhout <kleptog@svana.org> writes: > On Thu, Feb 16, 2006 at 07:28:20AM -0500, Robert Treat wrote: >> One problem is the only way for a client tool to work generically in prov= > ding >> data entry forms would be to provide entry for all columns, which would b= > reak >> in all but the most trivial of cases. Last time we discussed this for >> phppgadmin, the general opinion was it wasn't worth trying to work around= > >> postgresql core's deficiency. Once the core postgresql server supports >> updatable views in proper, I'd imagine this would get done. > In the general case, if there are any INSERT/UPDATE/DELETE RULEs on a > view, there is no way for the client to determine what the effect will > be except in the simplest of cases, letting the user specify seems the > best bet. I agree that this decision on phppgadmin's part seems unsupportable. Either there is an ON UPDATE rule on a view or there isn't --- it is not phppgadmin's job to determine what cases that rule supports. Try to do the update, and complain if it fails, is all that is required from a client-side tool. regards, tom lane
В списке pgsql-general по дате отправления: