Re: foreign key from array element - Mailing list pgsql-general

 Hi Chris,

    thank you very much for taking the time to read the article and get
 into the features proposed with our patch.

 On Tue, 18 Sep 2012 17:17:56 -0700, Chris Travers
 <chris.travers@gmail.com> wrote:
> So those are the cautions and why I don't think a feature like this
> is suitable for routine usage, but truth be told a lot of the
> object-relational features are definitely not for routine usage and
> make a mess of things if people use them just because they can.  I
> use table inheritance and I totally understand a lot of people's
> hostility towards this feature.  Again, anytime you break 1NF you
> should probably have a really good reason.  I don't think this
> changes here.

 I agree with you that this feature won't (and probably shouldn't)
 change modelling approaches in the majority of the cases. But will bring
 new opportunities, therefore make PostgreSQL even more versatile. I
 still believe that in some cases - not just indistinctively -
 aggregation in object oriented modelling can definitely be logically
 modelled using arrays, with referential integrity guaranteed by this
 feature.

> However, after thinking about the feature overnight, I can see a
> number of use cases for it, ranging from recording something like
> race
> results (where update contention is definitionally not an issue
> because the record of an event aren't supposed to change) to sanity
> checks in materialized views, and there are probably additional uses
> that are not apparent yet.

 I totally agree with you. This is exactly what we (as a community) need
 to do now as far as this feature is concerned. We need to have a larger
 use base and from there fully understand what the community needs. For
 instance, for 9.2 we had already developed actions on update and delete
 operations - assuming generic use cases. We have preferred for now to
 take out that part and start with a simpler patch where actions are
 forbidden. Through community feedback we found a name for the feature
 that was commonly accepted (we had called them EACH FOREIGN KEYS last
 year), and came up with an easy to understand syntax (and a better
 naming). It was important not to go too far down an unexplored
 territory. :)

> So yeah, as far as the feature goes, as documented, I haven't tried
> it fully yet (expect to do so this weekend), but it looks useful at
> least in some cases.

 Thank you. That's really much appreciated.

 Cheers,
 Gabriel
--
  Gabriele Bartolini - 2ndQuadrant Italia
  PostgreSQL Training, Services and Support
  Gabriele.Bartolini@2ndQuadrant.it - www.2ndQuadrant.it