Re: [PATCH] Store Extension Options
От | Robert Haas |
---|---|
Тема | Re: [PATCH] Store Extension Options |
Дата | |
Msg-id | CA+TgmobaodpbOt3738Nk0PUmqVASe7=iDoAhFuuLsyNsih_7sw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Store Extension Options (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: [PATCH] Store Extension Options
|
Список | pgsql-hackers |
On Wed, Mar 12, 2014 at 9:38 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > On 12 March 2014 22:58, Robert Haas <robertmhaas@gmail.com> wrote: >> I don't like the idea of using reloptions to let people attach >> arbitrary unvalidated settings to tables. > > I respect your opinion. If you disagree, don't use them. Same as is > possible for RULEs etc. That's not an answer. We don't let people put things in a date column that aren't actually dates, and we don't let people put things in an integer columns that aren't actually integers. Some other database have made different choices in those areas, and we've rightly chosen to more strict. Why is validation a good thing for the values that are stored in the tables but not a good idea for the metadata associated with those tables? > Experience was that requiring validation made things more brittle, > which is why we relaxed things a few releases ago. Opinions are one > thing, experience is quite another. Sure. But I think the reason why requiring validation made things more brittle is because the validation mechanism we used to have wasn't very good, not because validating stuff is in general not a good thing to do. > I'm not sure why this is being blocked. This is a community > contribution that seeks to improve everybody's options. Blocking it > does *nothing* to prevent individual extensions from providing > table-level options - we give them freedom to do whatever the hell > they want. Validation is a pipe dream, not *ever* an achievable > reality. Blocking is just exercise of a veto for nobody's gain. Unsurprisingly, I don't agree with any of that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: