Greetings. For some people the "what?" and "why?" of this will be immediately obvious from the title, but I'm going to spend a little time on those before "whether?" and "how?" We have schemata. They're namespaces; very convenient for organizing things. They let you group tables and other entities together, and, by setting search_path, only see the ones which presently interest you. In fact, they're pretty similar to directories in a filesystem... except that they don't nest. Imagine a filesystem where you could have directories, but the directories could only contain files, not other directories. (Like the first Unix on the PDP-7, or DOS before 2.0.) You could, of course, use your own delimiters. And we do; often along the lines of: schema.category_subcategory_table. You can't really use these to establish context, however. The system doesn't recognize category_subcategory as a "place". So you can't easily deal with a subset of your tables, and the combination of many tables and long names tends to be messy. So, for example, I'd like to be able to say something like this: SELECT * FROM /projects/contacts/people; Or: cd /projects/contacts; SELECT * FROM people; We use / for division, so that probably isn't plausible, but it makes for a familiar example. I'm wondering whether such a feature could be added, without breaking either existing code, or compliance with the SQL standard. For instance, borrowing :: from languages like Ruby and Perl: SELECT * FROM ::projects::contacts::people; -- Absolute path cd ::projects; -- Session-specific SELECT * FROM contacts::people; -- Relative path I'm not necessarily saying this is the best delimiter, but the colon isn't valid in unquoted identifiers, so it's probably a choice which would have minimal impact. Now, you could do a fair job of this just within the client, but my thought is that this would be better if actually supported by the database. For instance, having representation in the system tables. So, then: can it be done? Should it be done? I can say easily that my database life would be better for having this, but there do tend to be those nasty lurking problems which aren't obvious. -- Ray Brinzer
