"Mark Hollomon" <mhh@nortelnetworks.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
