On Tue, Jun 7, 2011 at 11:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> If your point here is that you don't want to spend time hacking on
>> this because it's a fairly marginal feature and therefore not terribly
>> high on your priority list, I can understand that. =A0But if you're
>> actually defending the current implementation, I'm going to have to
>> respectfully disagree. =A0It's broken, and it sucks, and this is not the
>> first complaint we've had about it.
>
> The spec's definition of USING is broken and sucky, and we're
> implementing it as best we can. =A0I don't feel a need to invent
> strange nonstandard behavior to work around the fact that USING
> is fragile *by definition*. =A0Complain to the standards committee
> about that.
It's not the standard's committee's fault that our dump won't restore.
They may not have made life any easier for us, but if we're going to
have the feature, then pg_dump ought to work. Otherwise, we're
telling people "you can use this feature, but don't expect to be able
to restore from backup". Not a way to win friends.
> (Question: would you also have us try to work around the fact that
> USING stops working if you rename one of the join columns?)
Yeah. In fact, I proposed a patch to do just that in response to bug
#5234, which you shot down. I still don't agree with that. We can
either disallow the original DDL (adding or renaming a column in a way
that causes the dumped representation to become invalid) or we can
change what we dump so that it can be reloaded. Letting the user
change the view definition and then producing an unrestorable dump
seems truly awful to me, regardless of how little help we're getting
from the SQL standards committee.
--=20
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
