On Sat, May 23, 2015 at 1:41 AM, Pavel Stehule <pavel.steh...@gmail.com> wrote: > > > 2015-05-22 18:34 GMT+02:00 Tom Lane <t...@sss.pgh.pa.us>: >> >> Oleksandr Shulgin <oleksandr.shul...@zalando.de> writes: >> > I think this is a bit over-engineered (apart from the fact that >> > processSQLNamePattern is also used in two dozen of places in >> > psql/describe.c and all of them must be touched for this patch to >> > compile). >> >> > Also, the new --table-if-exists options seems to be doing what the old >> > --table did, and I'm not really sure I underestand what --table does >> > now. >> >> I'm pretty sure we had agreed *not* to change the default behavior of -t. >> >> > I propose instead to add a separate new option --strict-include, without >> > argument, that only controls the behavior when an include pattern didn't >> > find any table (or schema). >> >> If we do it as a separate option, then it necessarily changes the behavior >> for *each* -t switch in the call. Can anyone show a common use-case where >> that's no good, and you need separate behavior for each of several -t >> switches? If not, I like the simplicity of this approach. (Perhaps the >> switch name could use some bikeshedding, though.) > > > it is near to one proposal > > implement only new long option "--required-table"
There is no updated version of the patch. So I marked this patch as "Waiting on Author". One very simple question is, doesn't -n option have very similar problem? Also what about -N, -T and --exclude-table-data? Not sure if we need to handle them in the similar way as you proposed. Isn't it sufficient to only emit the warning message to stderr if there is no table matching the pattern specified in -t? Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
