Re: [HACKERS] Packages: Again - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: [HACKERS] Packages: Again
Date
Msg-id cb99a8b5-9cb4-3adc-a76a-98e8efb0ac11@BlueTreble.com
Whole thread Raw
In response to Re: [HACKERS] Packages: Again  (Serge Rielau <serge@rielau.com>)
List pgsql-hackers
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)



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Patch to implement pg_current_logfile() function
Next
From: Jim Nasby
Date:
Subject: Re: [HACKERS] PSQL commands: \quit_if, \quit_unless