Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL

Tom, I agree with most of what you say. If we want to have ** be the
default
syntax for getting sub-columns I can live with that (for suggestion (3))

But for (2), I do feel very strongly that getting sub-tuples should be
the
"default default", and a SET GETSUBCLASSES=true should be the default
setting.

I've been using the postgres inheritance for a real system and I can
say with certainty that this is a massive source of errors. Not
wanting sub-class tuples seems rarely needed, and leaving off the "*" is
something that too often seems forgotten. I often can trawl through
code and realise that some query is missing the "*" but it hasn't been
discovered yet. In fact I find that almost all queries require the "*"
when you have a proper OO model, and not using "*" is usually laziness.

Also when adding a sub-class where there previously was none, one
usually has to trawl through the queries and add "*" to all of them
because as I said, there are almost never occasions where "*" is not
required in real life OO models.

So I understand the compatibility issue here, but I really feel strongly
that this should be changed now before there really are a lot of people
using it. Sure, have as many compatibility modes as you like, but I
think
this is a broken enough design that the default should be changed.
Apparently Illustra/Informix agreed.

Tom Lane wrote:
>
> "Mark Hollomon" <mhh(at)nortelnetworks(dot)com> writes:
> > How about a set variable?
>
> > SET GETSUBCLASSES = true
>
> > With the '*' and ONLY being explicit overrides to the setting
> > of the variable. The default would be 'false'.
>
> I like that a lot. Clean, flexible, doesn't break any existing
> applications.
>
> Perhaps the business of whether to fetch extra columns from subclasses
> could be done similarly. I am beginning to understand why Chris wants
> to do that, and I see that it would support a particular style of
> database programming very nicely. But I really fail to see why it's
> necessary to change the default behavior to cater to those apps rather
> than existing ones. Let the new apps use a variant syntax; don't
> expect people to change existing code in order to avoid getting tripped
> up by a new feature.
>
> Note that "oh they won't see the extra columns if they're using an
> old API" doesn't answer my objection. I'm concerned about the
> performance hit from fetching those columns and transferring them to
> the client, as well as the memory hit of storing them in query results
> on the client side. We should *not* set things up in such a way that
> that happens by default when the client didn't ask for it and isn't
> even using an API that can support it. That's why it'd be a mistake
> to redefine the existing query syntax to act this way.
>
> The suggestion of "SELECT ** FROM ..." sounds pretty good to me,
> actually. I don't really see any need for changing the behavior of
> anything that looks like a standard SQL query. Applications that
> need this feature will know that they need it and can issue a query
> that specifically requests it.
>
> > I would not object to a configuration switch that would change the
> > default.
>
> Mmm, I think that would probably not be such a hot idea. That would
> introduce a pretty fundamental semantics incompatibility between
> different installations, which would hurt script portability, complicate
> debugging and support, yadda yadda. I think a SET variable is enough...
>
> regards, tom lane