Re: narwhal and PGDLLIMPORT
От | Robert Haas |
---|---|
Тема | Re: narwhal and PGDLLIMPORT |
Дата | |
Msg-id | CA+TgmoZyspigBNttpEzvP4QS7oJUXHrQh+-Z7QEM7Wu0DjHQSw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: narwhal and PGDLLIMPORT (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: narwhal and PGDLLIMPORT
|
Список | pgsql-hackers |
On Tue, Feb 4, 2014 at 12:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> If someone volunteered to pay for the storage, I'd be prepared to make >> some time to create an AMI to reduce the startup time dramatically. >> Basically it would be "boot the AMI and start testing your patches". I'd >> even make it as friendly as possible for people who don't like to get >> too far from unix-ish environments. > > My own opinion is that I've already wasted untold man-hours thanks to > the random porting problems induced by Windows, a platform that I never > have and never will care about personally. I will *not* spend my own > time doing tests that someone else could do. If we can't get some > effort contributed by someone who does use that platform, I'm personally > prepared to declare the entire damn thing no longer supported. You know, I would really prefer to just stick a PGDLLIMPORT on this place and any others that need it, and any others that come up, than turn this into a political football. Having to sprinkle PGDLLIMPORT on the handful of variables that are accessed by contrib modules is, indeed, annoying. But it's not any more annoying than twelve other things that I have to do as a committer, like remembering to bump whichever of catversion, the xlog page magic, and the control data version are relevant to a particular commit, knowing which particular SGML files have to build standalone, and enforcing the project's code formatting, comment, and documentation conventions on everyone who submits a patch. So acting as if this particular annoyance is somehow unique or a good reason to desupport what is despite all of our misgivings one of our most popular platforms doesn't impress me one bit. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: