Re: [HACKERS] SQL objects UNITs
Robert Haas writes: > On Sat, Dec 21, 2013 at 12:10 PM, Dimitri Fontaine > wrote: >> Stephen Frost writes: >>> That said, I'm starting to wonder about a few >>> different options that might be handy- having the extension be dumpable >>> (or maybe an option to pg_dump to dump them from the DB, or not), and >>> perhaps an option to have the version # included in the dump (or an >>> option to exclude it, such as when run by pg_upgrade..?). Perhaps >>> similar things for pg_restore. >>> >>> In any case, this is certainly the way I had been hoping the discussion >>> would go.. >> >> http://www.postgresql.org/message-id/18778.1354753...@sss.pgh.pa.us > Fortunately, nobody's proposing that exact design, and I think there > are more recent emails where Tom expressed at least some support for > the idea of installing an extension purely via SQL, and in fact backed > the idea of being able to dump-and-restore the extension members as > superior to storing blobs in the catalog. AFAICT, what I was complaining about there was the idea that the per-extension behavior had to be specified via switches to pg_dump in order to get a valid dump. That doesn't seem too workable --- you think your nightly backup script will know that? But the idea that it's an alterable property of each extension, *stored in the database*, does not fall foul of that complaint. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SQL objects UNITs
On Sat, Dec 21, 2013 at 12:10 PM, Dimitri Fontaine wrote: > Stephen Frost writes: >> That said, I'm starting to wonder about a few >> different options that might be handy- having the extension be dumpable >> (or maybe an option to pg_dump to dump them from the DB, or not), and >> perhaps an option to have the version # included in the dump (or an >> option to exclude it, such as when run by pg_upgrade..?). Perhaps >> similar things for pg_restore. >> >> In any case, this is certainly the way I had been hoping the discussion >> would go.. > > http://www.postgresql.org/message-id/18778.1354753...@sss.pgh.pa.us Fortunately, nobody's proposing that exact design, and I think there are more recent emails where Tom expressed at least some support for the idea of installing an extension purely via SQL, and in fact backed the idea of being able to dump-and-restore the extension members as superior to storing blobs in the catalog. If you want to go beat your head against the wall, I don't blame you, but it's not going to help us make any progress here. -- 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: [HACKERS] SQL objects UNITs
Dimitri, * Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote: > Stephen Frost writes: > > That said, I'm starting to wonder about a few > > different options that might be handy- having the extension be dumpable > > (or maybe an option to pg_dump to dump them from the DB, or not), and > > perhaps an option to have the version # included in the dump (or an > > option to exclude it, such as when run by pg_upgrade..?). Perhaps > > similar things for pg_restore. > > > > In any case, this is certainly the way I had been hoping the discussion > > would go.. > > http://www.postgresql.org/message-id/18778.1354753...@sss.pgh.pa.us If you'd like to add to the discussion, then please do so. This isn't adding anything. Tom brings up good points in that thread from last year but my suggestion was about having a few options *in addition* to keeping track of how extensions were installed and using that as the default. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] SQL objects UNITs
Stephen Frost writes: > That said, I'm starting to wonder about a few > different options that might be handy- having the extension be dumpable > (or maybe an option to pg_dump to dump them from the DB, or not), and > perhaps an option to have the version # included in the dump (or an > option to exclude it, such as when run by pg_upgrade..?). Perhaps > similar things for pg_restore. > > In any case, this is certainly the way I had been hoping the discussion > would go.. http://www.postgresql.org/message-id/18778.1354753...@sss.pgh.pa.us -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SQL objects UNITs
* Andrew Dunstan (and...@dunslane.net) wrote: > >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. > > Yeah, seems like it might have merit. I like the simplicity of this approach as well, but I believe Tom had concerns about having some extensions behave quite different from others (hence the earlier suggetsion to name the 'dumpable' ones something different). That said, I'm starting to wonder about a few different options that might be handy- having the extension be dumpable (or maybe an option to pg_dump to dump them from the DB, or not), and perhaps an option to have the version # included in the dump (or an option to exclude it, such as when run by pg_upgrade..?). Perhaps similar things for pg_restore. In any case, this is certainly the way I had been hoping the discussion would go.. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] SQL objects UNITs
On 12/19/2013 08:01 AM, Robert Haas wrote: 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. Indeed. There might be limitations, but what we have is VERY useful. Let's keep things in proportion here. 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. Yeah, seems like it might have merit. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SQL objects UNITs
On 12/18/13, 4:22 AM, Dimitri Fontaine wrote: ALTER UNIT name SET SCHEMA ; FWIW, with the "units" that we've developed we use schemas to differentiate between public objects and "internal" (private or protected) objects. So single-schema stuff becomes a PITA. Of course, since extensions already work that way I suppose that ship has sailed, but I thought I'd mention it. For those who are curious... we make the distinction of public/protected/private via schemas because we don't want general users to need to wade through that stuff when looking at objects. So the convention we settled on is that public objects go in one schema, protected objects go in a schema of the same name that's prepended with "_", and private objects are in the protjected schema but also prepend "_" to their names. IE: CREATE SCHEMA awesome_feature; CREATE VIEW awesome_feature.have_some_data CREATE SCHEMA _awesome_feature; -- Protected / private stuff CREATE VIEW _awesome_feature.stuff_for_database_code_to_see_but_not_users CREATE FUNCTION _awesome_feature._do_not_run_this_function_anywhere_outside_of_awesome_feature() -- Jim C. Nasby, Data Architect j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
