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
