Robert Haas <robertmhaas@gmail.com> writes:
> Nobody has beaten me to it, but I thought of one potential issue.
> Suppose that somebody has a foreign table that exists today with one
> of these properties set to the empty string. Such a foreign table is
> not usable for queries, because the queries won't make it past scan.l
> on the remote side, but it's allowed to exist.
Hmm. A query not using that column would work just fine, so it's
at least arguable that there are such beasts in reality and the
user hasn't noticed the bug. (I doubt this, but if we're worrying
about improbable failures...)
> With this patch, it's
> not allowed to exist any more. That would be fine if no such objects
> exist in the wild, but if they do, people will get a pg_dump or
> pg_upgrade failure when they try to upgrade to a release that includes
> this change. Does that mean that we shouldn't commit this patch?
I was down on it to start with, on the grounds that it wasn't adding
enough ease-of-use to justify even a relatively small amount of added
code. I'm not sure that the dump-reload failure angle is much of a
concern in reality, but I would have voted not to commit before and
I still do.
regards, tom lane
