On Wed, 2008-05-14 at 23:29 +0300, Marko Kreen wrote:
> There are few code beautification ideas on which I'd like to
> get feedback from wider audience:
>
> - Drop CONNECT statement. This was added to make creating
> simple dblink style calls easier, but actually its not
> maintainable compa
On 5/18/08, Steve Singer <[EMAIL PROTECTED]> wrote:
> On Sat, 17 May 2008, Marko Kreen wrote:
> > On 5/17/08, Steve Singer <[EMAIL PROTECTED]> wrote:
> > > Somewhat unrelated, I can see use-cases for replacing the call to
> random()
> > > with something that allows user defined polices for RUN ON
On Sat, 17 May 2008, Marko Kreen wrote:
On 5/17/08, Steve Singer <[EMAIL PROTECTED]> wrote:
Somewhat unrelated, I can see use-cases for replacing the call to random()
with something that allows user defined polices for RUN ON ANY.
Well, thats why the RUN ON userfunc(..); exists. Also notice
On 5/17/08, Steve Singer <[EMAIL PROTECTED]> wrote:
> Somewhat unrelated, I can see use-cases for replacing the call to random()
> with something that allows user defined polices for RUN ON ANY.
Well, thats why the RUN ON userfunc(..); exists. Also notice the function
can tag more that one parti
Steve,
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
On Thu, 15 May 2008, Marko Kreen wrote:
On 5/15/08, Josh Berkus <[EMAIL PROTECTED]> 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
On 5/15/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > On 5/15/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> >>> Eg. how does src/backend/parser/gram.c not leak memory on syntax error?
> >>
> >> It's not a leak
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> On 5/15/08, Tom Lane <[EMAIL PROTECTED]> wrote:
>> "Marko Kreen" <[EMAIL PROTECTED]> writes:
>>> Eg. how does src/backend/parser/gram.c not leak memory on syntax error?
>>
>> It's not a leak because the memory can be re-used during the next
>> command.
On 5/15/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > Eg. how does src/backend/parser/gram.c not leak memory on syntax error?
>
> It's not a leak because the memory can be re-used during the next
> command.
I may be blind, but I don't see any static varia
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> Eg. how does src/backend/parser/gram.c not leak memory on syntax error?
It's not a leak because the memory can be re-used during the next
command.
I believe you'll find that trying to make it use palloc is a failure
because it keeps static pointers that
On 5/15/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > How about following patch? I have bison 2.3 and it seems not to do
> > global allocation, so it should be fine. There may be early exit
> > with elog(ERRROR) inside so I'd like to avoid malloc() itse
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> How about following patch? I have bison 2.3 and it seems not to do
> global allocation, so it should be fine. There may be early exit
> with elog(ERRROR) inside so I'd like to avoid malloc() itself.
None of our other parsers fool with bison's memory al
On 5/15/08, Marko Kreen <[EMAIL PROTECTED]> wrote:
> On 5/15/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> > "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > > 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
On 5/15/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > 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?
>
> Yes.
How about following patch?
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> 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?
Yes.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsq
On 5/15/08, Josh Berkus <[EMAIL PROTECTED]> wrote:
> On Wednesday 14 May 2008 13:29, Marko Kreen wrote:
> > - SGML documentation.
> > - Makefile review.
> > - Integrate regression tests into main test framework.
>
> Has PL/proxy been tested on other OSes? FreeBSD/Solaris/Windows?
It definitely
On Wednesday 14 May 2008 13:29, Marko Kreen wrote:
> - SGML documentation.
> - Makefile review.
> - Integrate regression tests into main test framework.
Has PL/proxy been tested on other OSes? FreeBSD/Solaris/Windows?
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
--
Sent via pgsql-hac
Please consider this mail as submission of PL/Proxy into core.
Documentation:
https://developer.skype.com/SkypeGarage/DbProjects/PlProxy
Previous submission with overview:
http://archives.postgresql.org/pgsql-hackers/2007-03/msg01763.php
- The code has changed rather little compared to fir
18 matches
Mail list logo
