RE: automatic restore point

Поиск
Список
Период
Сортировка
От Yotsunaga, Naoki
Тема RE: automatic restore point
Дата
Msg-id 8E9126CB6CE2CD42962059AB0FBF7B0DBF4976@g01jpexmbkw23
обсуждение исходный текст
Ответ на Re: automatic restore point  (Michael Paquier <michael@paquier.xyz>)
Ответы RE: automatic restore point  ("Yotsunaga, Naoki" <yotsunaga.naoki@jp.fujitsu.com>)
Список pgsql-hackers
>-----Original Message-----
>From: Michael Paquier [mailto:michael@paquier.xyz] 
>Sent: Tuesday, July 3, 2018 10:22 AM

>This kind of thing is heavily application-dependent.  For example, you would likely not care if an operator, who has
newly-joinedthe team in >charge of the maintenance of this data, drops unfortunately a table which includes logs from
10years back, and you would very likely care >about a table dropped which has user's login data.  My point is that you
needto carefully design the shape of the configuration you would use, >so as any application's admin would be able to
copewith it, for example allowing exclusion filters with regular expressions could be a good >idea to dig into.  And
alsoyou need to think about it so as it is backward compatible.
 

Thanks for comments.

Does that mean that the application (user) is interested in which table?
For example, there are two tables A. It is ok even if one table disappears, but it is troubled if another table B
disappears.So, when the table B is dropped, automatic restore point works. In the table A, automatic restore point does
notwork.
 
So, it is difficult to implement that automatic restore point in postgresql by default.
Is my interpretation right?

---
Naoki Yotsunaga



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: small doc fix - using expressions in plpgsql FETCH command
Следующее
От: "Yotsunaga, Naoki"
Дата:
Сообщение: RE: automatic restore point