On 12/16/2013 11:44 AM, Tom Lane wrote:> Right. I think a lot of the
tension comes from people being unconvinced
> that the existing extension feature is an ideal model for this sort of
> use-case. Extensions were mainly designed around the notion of a .so
> with some SQL datatype/function/etc declarations that have to match up
> with the C code. So it made sense for them to be relatively static things
> that live in the filesystem. Notably, if you're migrating to a new PG
> major version, you're at the very least gonna have to recompile the C code
> and quite likely will need to change it some. So adapting the SQL code
> if needed goes along with that, and would never be automatic in any case.
I see what you mean. On the other hand:
a) introducing a new concept would require a new reserved word
b) it would also require figuring out how it interacts with extensions
c) extensions already have versioning, which this feature needs
d) extensions already have dependancies, which this feature needs
While it splits Extensions into two slightly different concepts, I find
that on the whole less confusing than the alternative.
On 12/16/2013 05:17 PM, Jim Nasby wrote:
> Somewhat related to this, I really wish Postgres had the idea of a
> "class", that was allowed to contain any type of object and could be
> "instantiated" when needed. For example, if we had an "address class",
> we could instantiate it once for tracking our customer addresses, and a
> second time for tracking the addresses customers supply for their
> employers. Such a mechanism would probably be ideal for what we need,
> but of course you'd still have the question of how to load a class
> definition that someone else has published.
Well, the idea originally (POSTGRES) was for the Type, Domain, and
Inheritance system to do just what you propose. Nobody ever worked out
all the practicalities and gotchas to make it really work in production,
though.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
