"David E. Wheeler" <da...@kineticode.com> writes: >> What about unaccent? Or lo (1 domain, 2 functions)? > > Sure. Doesn't have to actually do anything.
Ok, so that's already in the patch :) >> That's called a shared catalog. I don't see any benefit of having to >> maintain that when we do already have a directory containing the files >> and the restriction that extensions names are the file names. > > Because then you don't need control files at all. > >> Again, if you really want to have that, you have to first detail how and >> you fill in the shared catalog, and update it. > > `make install` should do it. From variables in the Makefile. I see that you're not too much into packaging, but here, we don't ever use `make install` on a production machine. This step happens on the packaging server, then we install and QA the stuff, then the package gets installed on the servers where we need it. Also, I don't see how make install is going to know which cluster it should talk to — it's quite easy and typicall to run this command on a server where you have several major versions installed, and several clusters per major version. So, again, the data that you so want to remove from the control files I have no idea at all where to put it. > Possibly. I'm not going to do it this week; seems like there are some > issues that still need shaking out in the implementation, to judge > from the "pg_execute_from_file review" thread. Yeah, dust ain't settled completely yet… working on that. > Each would get a separate control file. The mapping of one version > number to multiple extensions is potentially confusing. Funny, each already get a separate control file now. $ ls contrib/spi/*control.in autoinc.control.in auto_username.control.in moddatetime.control.in refint.control.in timetravel.control.in Then the idea behind the version number in the Makefile is that you generally are maintaining it there and don't want to have to maintain it in more than one place. > Why is that? We currently manage multiple script files, test files, > etc. in a single Makefile. Wildcard operators are very useful for this > sort of thing. Well, that was you saying just above that using the same EXTVERSION Make variable for more than one control file is "potentially confusing". What about using all the other variables in the same way? >> Well, before that you had to explicitly write public in there, which IMO >> is so much worse. Then again, I now think that the right way to approach >> that is to remove this feature. The user would have a 2-steps operation >> instead, but that works right always. > > Yes, that would be preferable, but a one-step operation would of > course be ideal. Thinking about it, as proposed in the other thread, I now think that the 2-steps operation could be internal and not user exposed. >> ALTER EXTENSION name SET SCHEMA foo TO bar, baz TO quux; > > Perhaps. v2, eh? ;-P Yes please :) > Some do require shared_preload_libraries, no? One of them only, pg_stat_statements. > SET client_min_messages TO warning; > SET log_min_messages TO warning; > > Though I think I'd rather that the warning still went to the log. (that's about hstore verbosity) ok will see about changing client_min_messages around the CREATE OPERATOR =>. Regards, -- 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
