> > The following patch addresses this issue by making libpgport usable
> > unchanged by client applications, and makes a special
> server version
> > for the backend.
>
> This raises some alarm bells for me. Why does a "port
> support" library need to distinguish whether it is running in
>
Magnus Hagander wrote:
> > > The following patch addresses this issue by making libpgport usable
> > > unchanged by client applications, and makes a special
> > server version
> > > for the backend.
> >
> > This raises some alarm bells for me. Why does a "port
> > support" library need to dis
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > The following patch addresses this issue by making libpgport usable
> > unchanged by client applications, and makes a special server version for
> > the backend.
>
> This raises some alarm bells for me. Why does a "port support" libr
Neil Conway wrote:
> Pasto:
>
> *** src/bin/pg_config/Makefile 1 Aug 2004 06:56:38 - 1.8
> --- src/bin/pg_config/Makefile 1 Oct 2004 04:04:06 -
> ***
> *** 1,18
> [...]
> --- 1,23
> !
> #-
The patch below removes attempts to drop objects before creating them
from the int_aggregate and pgstattuple SQL scripts. This causes the
script to fail on databases where the affected objects don't already
exist when the script is executed by the Win32 installer, pgAdmin or any
other interface tha
any comments on my last patch?
--
g.gRay: PL/perl, PL/PHP ;)
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Sergej Sergeev wrote:
any comments on my last patch?
Speaking for myself, I am not really thinking much about new plperl
stuff until we get closer to branching the code, which as I understand
the current processes would be at the time we release an RC - that seems
a little way off yet.
cheers
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> + #include
>>
>> What is this change for?
> My OS couldn't compile getaddrinfo when I tried, though my OS doesn't
> need getaddrinfo so maybe we shouldn't make that change. Comments?
Don't put it in. That looks like the sort of file that isn't even
"Dave Page" <[EMAIL PROTECTED]> writes:
> The patch below removes attempts to drop objects before creating them
> from the int_aggregate and pgstattuple SQL scripts. This causes the
> script to fail on databases where the affected objects don't already
> exist when the script is executed by the Win
Reini Urban wrote:
> I think that LDFLAGS overriding is in some situations bad for newer
> libtool, as it is used with some postgresql contrib makefiles and
> interfaces.
We're not using libtool.
> LIBS are added to LDFLAGS where they really should be added to
> LIBS, not LDFLAGS.
> This causes i
>> Hello!
>>
>> Here is a patch to fix win32 ssl builds. Summary of changes:
>>
>
>>
>> I'd appreciate it if one of the win32 guys can confirm that
>> this patch fixes the build for them as well.
>
>Yup, looks good to me. Compiles OK and SSL appears to work
>just fine :-)
Okay. Then please co
I have attached 5 patches (split up for ease of review) to plperl.c.
1. Two minor cleanups:
- We don't need to call hv_exists+hv_fetch; we should just check the
return value of hv_fetch.
- newSVpv("undef",0) is the string "undef", not a real undef.
2. This should fix the bug Andrew
On Fri, Oct 01, 2004 at 11:59:56AM +1000, Neil Conway wrote:
> On Thu, 2004-09-30 at 10:30, ljb wrote:
> > These corrections against 8.0.0beta3 are for removal of the Tcl interface
> > from core.
>
> Patch applied to HEAD, with some editorializing. autoconf (2.53) re-run.
>
> For future reference
Tom Lane wrote:
> Euler Taveira de Oliveira <[EMAIL PROTECTED]> writes:
> > This small patch correct a hint style and change from multiple to
> > single line comment because gettext seems not to like multiple line
> > comments. Then we could see the "translator: ..." in po files too.
>
> I believe
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> + #include
> >>
> >> What is this change for?
>
> > My OS couldn't compile getaddrinfo when I tried, though my OS doesn't
> > need getaddrinfo so maybe we shouldn't make that change. Comments?
>
> Don't put it in. That looks like
Bruce Momjian wrote:
> As many know, the FRONTEND usage of /src/port is very fragile. It
> requires every binary that uses certain libpgport object files to create
> its own version, which is very fragile, and could easily break if a
> function call is added in a subrelease, especially on certain
16 matches
Mail list logo