Re: [HACKERS] Proposal for psql wildcarding behavior w/schemas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here's my thoughts on the matter: More than one period throws an error (something pleasant, mentioning that we do not quite support cross-database queries yet). I'll assume we are switching to the explicit wildcard system for this. (I think the proposed *? wildcards are a great idea). Basically, for those functions (esp. \d) that can return a list or a single item, the wildcard indicates that we want a list, and a lack of wildcard indicates we want a single item. \d foo.bazShows details about the table bar in the schema foo \d bazAttempts to find a visible baz in the schemas, shows first one that matches. \d baz* Shows all tables starting with baz, in all available schemas \d *.baz* Same as above \d baz.* Shows all tables in the baz schema \d foo.baz* Shows all tables starting with baz in the foo schema \d *.baz Similar to \d baz, but the wildcard forces all matches to be shown. \d foo*.baz Shows all tables named baz in schemas staring with foo \d *.*Same as plain old \d (which is actually a special case now) \d *oo. Matches all tables in schemas ending in oo \d *oo.* Same as above - a plain * on either side of the dot is usually superfluous, except that it forces a list of matches. The only one I have a problem with is the '\d baz' which some may argue should continue the current behavior and return details about the first baz table it encounters. On the other hand, people really need to start thinking about schemas and the consequences of having more than one table named baz. Still, typing in the schema could get tedious very quickly. Perhaps it should only return a list if more than one table was found, otherwise it will return information about that table. The good thing about the above is that \d and \dt will actually have the same functionality. The current behavior can be a bit confusing, in that some functions have implicit wildcards (\dt and friends) and some do not (\d). Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200208091849 -BEGIN PGP SIGNATURE- Comment: http://www.turnstep.com/pgp.html iD8DBQE9VEb6vJuQZxSWSsgRAsHNAKDCXz4vUY1A79EaVmfPIfcNS7VyxgCaA5Tx HrNmY0vITbb2G1fZFBCPgBM= =qhYp -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Proposal for psql wildcarding behavior w/schemas
Greg Sabino Mullane [EMAIL PROTECTED] writes: Here's my thoughts on the matter: More than one period throws an error (something pleasant, mentioning that we do not quite support cross-database queries yet). The just-committed implementation doesn't throw an error, but silently discards name fragments to the left of the last two --- for example, foo.bar.baz is silently treated as bar.baz. This could probably be improved, but I haven't quite figured out how psql deals with error recovery... Otherwise I agree with your comments, except for \d baz* Shows all tables starting with baz, in all available schemas Make that shows visible tables whose names begin with baz. There is a subtle difference. \d *.baz* Same as above This shows tables whose names begin with baz, in any schema in the database --- without regard to visibility. \d *.*Same as plain old \d (which is actually a special case now) \d without an argument is still a special case: it transforms to \dtvs with no argument. Other than that little usability kluge, the general rule is that for any object-type x, \dx is the same as \dx *, which is *not* the same as \dx *.* ... the former shows all visible objects, the latter all objects in the database. The current behavior can be a bit confusing, in that some functions have implicit wildcards (\dt and friends) and some do not (\d). As of cvs tip, all the \d family take wildcards. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Proposal for psql wildcarding behavior w/schemas
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: 1. A wildcardable pattern must consist of either namepattern or namepattern.namepattern. Regarding the use of quotes: Would \d foo.bar show the table foo.bar, whereas \d foo.bar would show the table bar in schema foo? That'd be my interpretation of what it should do. Okay with you? regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
