Re: Extensions, this time with a patch
От | David E. Wheeler |
---|---|
Тема | Re: Extensions, this time with a patch |
Дата | |
Msg-id | DF8A3229-2C5B-4B2C-A2D4-C91315DF5EE7@kineticode.com обсуждение исходный текст |
Ответ на | Re: Extensions, this time with a patch (Dimitri Fontaine <dimitri@2ndQuadrant.fr>) |
Ответы |
Re: Extensions, this time with a patch
|
Список | pgsql-hackers |
On Oct 21, 2010, at 8:12 AM, Dimitri Fontaine wrote: > That's a good idea, but my guess is that the implementation cost of > supporting the control format in your perl infrastructure is at least an > order of magnitude lower than the cost for me to support your current > JSON file format, so I lean towards you having an automated way to fill > in the json file from the control one... Well, it *will* be easier. Eventually. Right now, the file has to be edited by hand. Which I can tell you from experienceis rather…error-prone. Anyway, I wouldn't push for a JSON file format until a parser was just there for you to use without too much trouble. > The Makefile supports $(VERSION) because chances are it's already there > (think packaging or tarball release targets). Having yet another place > where to manually maintain a version number ain't appealing. Be aware that PGXS sets a $(VERSION) variable already, so you'll need to use another name, I think, to guard from conflicts.This is in Makefile.global: VERSION = 9.0.1 MAJORVERSION = 9.0 Maybe use EXTVERSION? You don't want to overwrite the core version because a makefile author could use it to change the build(pgTAP does this, for example). > In the latest patch, though, the only other thing you find in the > Makefile about the extension is its basename, which must be the one of > both the .control and the .sql files. And it's possible for $(EXTENSION) > to be a list of them, too, because of contrib/spi. Right, that makes sense. Best, David
В списке pgsql-hackers по дате отправления: