Re: Exposing PG_VERSION_NUM in pg_config
От | Jim Nasby |
---|---|
Тема | Re: Exposing PG_VERSION_NUM in pg_config |
Дата | |
Msg-id | 5522CC2D.2070309@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: Exposing PG_VERSION_NUM in pg_config (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
Список | pgsql-hackers |
On 4/1/15 1:25 AM, Andrew Gierth wrote: >>>>>> "Michael" == Michael Paquier <michael.paquier@gmail.com> writes: > > Michael> For an extension that has a single branch compatible with a > Michael> set of multiple major versions of Postgres, the cases are > Michael> custom values for REGRESS_OPTS and REGRESS depending on the > Michael> backend version. I also manipulate on a daily basis the same > Michael> set of scripts across many platforms (on Windows as well using > Michael> msysgit, and MSVC installation does not have pgxs stuff), so I > Michael> would use it to simplify them. It is true that you can already > Michael> do that by parsing the output of "pg_config --version", > > What _exactly_ would you be doing that you could not already do better > with $(MAJORVERSION) which is already defined in Makefile.global? FWIW, I'm currently using this as a poor-man's version of configure, to deal with some minor changes to function parameters between versions. I probably would also need to screw around with regression tests but I've given up on pretty much the whole idea of our regression methodology and use pgTap instead. I do still run it using the built-in framework, because of all the other stuff I get. If I had some way to just over-ride the notion of "diff the output" I'd do that. If I wasn't using pgTap I'm pretty sure I'd be having fun and games with cross-version output tweaking. -- Jim Nasby, Data Architect, Blue Treble Consulting Data in Trouble? Get it in Treble! http://BlueTreble.com
В списке pgsql-hackers по дате отправления: