On Tue, 26 Feb 2002, Josh Berkus wrote:
> David,
>
> > Anyway, couldn't it be an extention to postgreSQL ? If you have heard
> > about
> > Business Objects, you should know that it can do it very well
> > provided you
> > draw the relationchips between the tables of your database. And it's
> > of much
> > use, since you just have to concentrate on the fields you want to
> > fetch and
> > the program takes care of the relations and handles group by, order
> > by and
> > where clause.
>
> Certainly it could. However, the project needs a really persuasive
> reason to transgress the SQL standard. That is, substantial
> funcitonality needs to be gained from the extension, sufficient to
> offset the issues raised with porting applications to and from
> Postgresql.
>
> However, there appears to be a way to give you what you want without
> violating the standard: we could make Natural Join work for
> foriegn-keyed columns, not just columns with similar names. This would
> give us some useful funcitionality without breaking the standard.
If we were to do this, I'd say using NATURAL JOIN is a bad idea. It'd
be better to make a new join type since otherwise it'd have unexpected
behavior for someone who knew the spec but not the change.
Also, this still needs more definition. What do we do with multiple
foreign keys, especially ones where the schema has recursive ones? What
about match types and NULLs -- is it equality or "matchness" we care
about? It may be a good idea, but it needs some fleshing out. :)