On Apr 20, 2011, at 8:04 PM, Daniele Varrazzo wrote: > Specifically, I parse the version from the control file using: > > PGMP_VERSION=$(shell grep default_version pgmp.control | sed -e > "s/default_version = '\(.*\)'/\1/")
Oh, that's not bad. Thanks. > so the Makefile doesn't have to be maintained for it. To tell apart < > 9.1 and >= 9.1 I've used instead: > > PG91 = $(shell $(PG_CONFIG) --version | grep -qE " 8\.| 9\.0" && > echo pre91 || echo 91) > ifeq ($(PG91),91) > ... > else > ... Oh, definitely better and more future-proof than what I had. Mind if I poach these examples and document them for PGXN distribution? > For my extension I'm less concerned by having the install sql named in > different ways or by the upgrade sql as all these files are generated > by scripts. You may find useful this one > <https://github.com/dvarrazzo/pgmp/blob/master/tools/sql2extension.py> > to generate the upgrade sql from the install sql. For my extension I > require Python and have all the sql files generated by the Makefile at > install time; if you don't want this dependency you ma Yeah, I recently started using Perl to break up pgTAP into multiple files. I struggled for a while over whether or not to require it or to build the files at distribution time. I finally settled for having it run at install time, but it's not required: you just wouldn't get the broken-up files without it, only the great big one. I guess one could do the same with your script: If you don't have python, you don't get the unpackaged migration scripts. Thanks again, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
