On 1/13/17 10:56 PM, Serge Rielau wrote:
> But what irks me in this debate is that any reasoned and detailed
> argumentation of value of the principle itself is shut down with
> un-reasoned and un-detailed one-liners.
> “I’m not convinced” is not an argument.
> Counterpoints require content. Something starting with “because …”
+1.
I really can't fathom how someone can flatly say that a nested namespace
is a dumb idea. Your filesystem does this. So does plpgsql. I could
absolutely make use of nested "schemas" (or make it some other feature
if "nested schema" offends you so much).
I agree that a nested namespace might violate ANSI (depending on if you
overload schema/module), and that it might be hard to do with how
Postgres currently works. And those may be reason enough not to attempt
the effort. But those have *nothing* to do with how useful such a
feature would be to users.
This is similar to the 10+ years users would ask for "DDL triggers" and
get jumped all over because of how hard it would be to actually put a
trigger on a catalog table. Thankfully someone that knew the code AND
understood the user desire came up with the notion of event triggers
that put hooks into every individual DDL command. Users got what they
wanted, without any need to put "real triggers" on catalog tables.
FWIW, what I wish for in this area is:
- SOME kind of nested namespace for mulitple kinds of objects (not just
functions)
- A way to mark those namespaces (and possibly other objects) as private.
- A way to reference extensions from other extensions and deal with
extensions being moved to a different schema (or namespace).
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)