Pavel Stehule <pavel.stehule@gmail.com> writes: > > 2015-03-23 17:11 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>: > >> Hi >> >> 2015-03-15 16:09 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>: >> >>> Pavel Stehule <pavel.stehule@gmail.com> writes: >>> > other variant, I hope better than previous. We can introduce new long >>> > option "--strict". With this active option, every pattern specified by >>> -t >>> > option have to have identifies exactly only one table. It can be used >>> for >>> > any other "should to exists" patterns - schemas. Initial implementation >>> in >>> > attachment. >>> >>> I think this design is seriously broken. If I have '-t foo*' the code >>> should not prevent that from matching multiple tables. What would the use >>> case for such a restriction be? >>> >>> What would make sense to me is one or both of these ideas: >>> >>> * require a match for a wildcard-free -t switch >>> >>> * require at least one (not "exactly one") match for a wildcarded -t >>> switch. >>> >> >> >> attached initial implementation >> > > updated version - same mechanism should be used for schema
Hello,
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).
it was prototype - I believe so issue with describe.c can be solved better
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 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).
hard to say - any variant has own advantages and disadvantages
But I more to unlike it than like - it is more usual, when you use exact name so, you need it exactly one, and when you use some wildcard, so you are expecting one or more tables.
