Re: SQL objects UNITs (was: [HACKERS] Extension Templates S03E11)
Le jeudi 19 décembre 2013 14:01:17, Robert Haas a écrit :
> On Wed, Dec 18, 2013 at 10:05 AM, Alvaro Herrera
>
> wrote:
> > Stephen Frost escribió:
> >> * Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> >> > Basically with building `UNIT` we realise with hindsight that we
> >> > failed to build a proper `EXTENSION` system, and we send that message
> >> > to our users.
> >>
> >> Little difficult to draw conclusions about what out 'hindsight' will
> >> look like.
> >
> > I haven't been keeping very close attention to this, but I fail to see
> > why extensions are so much of a failure. Surely we can invent a new
> > "kind" of extensions, ones whose contents specifically are dumped by
> > pg_dump. Regular extensions, the kind we have today, still wouldn't,
> > but we could have a flag, say "CREATE EXTENSION ... (WITH DUMP)" or
> > something. That way you don't have to come up with UNIT at all (or
> > whatever). A whole new set of catalogs just to fix up a minor issue
> > with extensions sounds a bit too much to me; we can just add this new
> > thing on top of the existing infrastructure.
>
> Yep.
>
> I'm not very convinced that extensions are a failure. I've certainly
> had plenty of good experiences with them, and I think others have as
> well, so I believe Dimitri's allegation that we've somehow failed here
> is overstated. That having been said, having a flag we can set to
> dump the extension contents normally rather than just dumping a CREATE
> EXTENSION statement seems completely reasonable to me.
>
> ALTER EXTENSION foo SET (dump_members = true/false);
>
> It's even got use cases outside of what Dimitri wants to do, like
> dumping and restoring an extension that you've manually modified
> without losing your changes.
Isn't there some raw SQL extension author are supposed to be able to push in
order to dump partial configuration table and similar things (well, what we're
supposed to be able to change in an extension).
yes, it is:
SELECT pg_catalog.pg_extension_config_dump('my_config', 'WHERE NOT
standard_entry');
(it is raw SQL here, but it is not appreciated for Extension 'Templates'
I stopped trying to figure/undertand many arguments in those Extension email
threads)
Maybe something around that to have also the objects created by extension
dumped, and we're done. I even wnder if Dimitri has not already a patch for
that based on the work done for Extensions feature.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
Re: SQL objects UNITs (was: [HACKERS] Extension Templates S03E11)
On Wed, Dec 18, 2013 at 10:05 AM, Alvaro Herrera wrote: > Stephen Frost escribió: >> * Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote: > >> > Basically with building `UNIT` we realise with hindsight that we failed to >> > build a proper `EXTENSION` system, and we send that message to our users. >> >> Little difficult to draw conclusions about what out 'hindsight' will >> look like. > > I haven't been keeping very close attention to this, but I fail to see > why extensions are so much of a failure. Surely we can invent a new > "kind" of extensions, ones whose contents specifically are dumped by > pg_dump. Regular extensions, the kind we have today, still wouldn't, > but we could have a flag, say "CREATE EXTENSION ... (WITH DUMP)" or > something. That way you don't have to come up with UNIT at all (or > whatever). A whole new set of catalogs just to fix up a minor issue > with extensions sounds a bit too much to me; we can just add this new > thing on top of the existing infrastructure. Yep. I'm not very convinced that extensions are a failure. I've certainly had plenty of good experiences with them, and I think others have as well, so I believe Dimitri's allegation that we've somehow failed here is overstated. That having been said, having a flag we can set to dump the extension contents normally rather than just dumping a CREATE EXTENSION statement seems completely reasonable to me. ALTER EXTENSION foo SET (dump_members = true/false); It's even got use cases outside of what Dimitri wants to do, like dumping and restoring an extension that you've manually modified without losing your changes. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: SQL objects UNITs (was: [HACKERS] Extension Templates S03E11)
Stephen Frost escribió: > * Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote: > > Basically with building `UNIT` we realise with hindsight that we failed to > > build a proper `EXTENSION` system, and we send that message to our users. > > Little difficult to draw conclusions about what out 'hindsight' will > look like. I haven't been keeping very close attention to this, but I fail to see why extensions are so much of a failure. Surely we can invent a new "kind" of extensions, ones whose contents specifically are dumped by pg_dump. Regular extensions, the kind we have today, still wouldn't, but we could have a flag, say "CREATE EXTENSION ... (WITH DUMP)" or something. That way you don't have to come up with UNIT at all (or whatever). A whole new set of catalogs just to fix up a minor issue with extensions sounds a bit too much to me; we can just add this new thing on top of the existing infrastructure. I didn't much like the WITH UNIT/END UNIT thingy. What's wrong with CREATE foo; ALTER EXTENSION ADD foo? There's a bit of a problem that if you create the object and die before being able to add it to the extension, it would linger unreferenced; but that's easily fixable by doing the creation in a transaction, I think. (Alternatively, we could have a single command that creates the extension and the contained objects in one fell swoop, similar to how CREATE SCHEMA can do it; but I'm not sure that's all that much better, and from a grammar POV it probably sucks.) -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: SQL objects UNITs (was: [HACKERS] Extension Templates S03E11)
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote: > Here's my attempt: > > # Inline Extension, Extension Templates > > The problem with *Inline Extension* is the dump and restore policy. The > contents of an extensions are not be found in a `pg_dump` script, ever. You keep coming back to this and I think you're taking too narraw a view to the comments made on the prior threads. No, we don't really want extensions which have .sql files out on disk somewhere as part of them to be dumped out through pg_dump because then it becomes unclear which set of scripts should be used during restore. What we're talking about here is intended to not have that issue by using a different namespace, a flag, something which identifies these extensions as being defined through the catalog instead. > # The new thing™ > > A set of SQL objects that can be managed wholesale, with a version string > attached to it. Objects are part of `pg_dump` output, the whole set can be > relocatable, and has a version string attached. I'd like to see more than just a single version string included and I think that'd be beneficial for extensions too. > Name: [...] > I'll pick UNIT here. We can figure that later. > Commands: > > CREATE UNIT name [ SCHEMA ... ] [ [ NOT ] RELOCATABLE ] [ REQUIRE ...]; > > WITH UNIT name; > > END UNIT name; Interesting approach- I had considered something similar by having a 'fake' schema created into which you built up the 'UNIT'. The reason I was thinking schema instead of begin/end style commands, as you have above, is because of questions around transactions. Do you think the syntax you have here would require the definition to be all inside of a single transaction? Do we feel that would even be an issue or perhaps that it *should* be done that way? I don't currently have any strong feelings one way or the other on this and I'm curious what others think. > The `UPDATE TO` command only sets a new version string. So, one of the things I had been wondering about is if we could provide a 'diff' tool. Using your 'WITH UNIT' syntax above, an author might need to only write their initial implementation, build up a 'UNIT' based on it, then adjust that implementation with another 'WITH UNIT' clause and then ask PG for the differences. It's not clear if we could make that work but there is definitely a set of desireable capabilities out there, which some other databases have, around automated upgrade script building and doing schema differences. > # Implementation details > # Event Trigger support Not sure we're really ready to get into these yet. > The main drawback is that rather than building on extensions, both in a > technical way and in building user trust, we are basically going to > deprecate extensions entirely, giving them a new name an an incompatible way > to manage them. I don't see this as ending up deprecating extensions, even if we build a new thing with a new name. I would argue that properly supported extensions, such as those in contrib and the other 'main' ones, like PostGIS, and others that have any external dependencies (eg: FDWs) would almost certainly continue as extensions and would be packaged through the normal OS packaging systems. While you plan to use the event trigger mechanism to build something on top of this which tries to act like extenisons-but-not, I think that's an extremely narrow and limited use-case that very few people would have any interest in or use. > Basically with building `UNIT` we realise with hindsight that we failed to > build a proper `EXTENSION` system, and we send that message to our users. Little difficult to draw conclusions about what out 'hindsight' will look like. Thanks, Stephen signature.asc Description: Digital signature
