Re: [rfc,patch] PL/Proxy in core
От | Steve Singer |
---|---|
Тема | Re: [rfc,patch] PL/Proxy in core |
Дата | |
Msg-id | BAYC1-PASMTP046F29E3959C78E3963C7FACCB0@CEZ.ICE обсуждение исходный текст |
Ответ на | Re: [rfc,patch] PL/Proxy in core ("Marko Kreen" <markokr@gmail.com>) |
Ответы |
Re: [rfc,patch] PL/Proxy in core
Re: [rfc,patch] PL/Proxy in core |
Список | pgsql-hackers |
On Thu, 15 May 2008, Marko Kreen wrote: > On 5/15/08, Josh Berkus <josh@agliodbs.com> wrote: >> Has PL/proxy been tested on other OSes? FreeBSD/Solaris/Windows? > > It definitely works on Linux and MacOS. I've seen ports for *BSD. > I think any unix-like OS-es should work fine. I've compiled it with a minor Makefile modification on Solaris and it seems to work (it passes all the unit tests but the one involving random; we might want to rethink that test so 'passes' on platforms with different implementations of random()). However, I haven't deployed it into a production environment. Somewhat unrelated, I can see use-cases for replacing the call to random() with something that allows user defined polices for RUN ON ANY. > > In fact, only syscalls it does on its own are gettimeofday() and poll() > [or select()], otherwise it calls either core or libpq functions. > So I see no reason why it shouldnt already work on Windows. > > The biggest portability problem thus far has been scanner.l, which at > the beginning was written for flex 2.5.33+, but 2.5.4 is still pretty > widespread. But this I fixed in 2.0.3. > > Hmm.. Now that I think about it, in my effort to remove malloc() calls > in both scanner and parser I told bison to use alloca(). Is it portability > concern? Easy to fix, just need to be careful not to create memleaks. > > -- > marko > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
В списке pgsql-hackers по дате отправления: