This patch makes mention to use the newer pg_dump when migrating, as suggested
by a few folks.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Index: backup.sgml
===
RCS file: /projects/cvsroot/pgsql-se
Patch applied. Thanks.
---
Euler Taveira de Oliveira wrote:
> Hi Bruce,
>
> This is a small update for FAQ_brazilian.html. Don't forget to generate
> the text version.
>
>
> =
> Euler Taveira de Oliveira
> euler[at]
Hi,
This is the pg_dump translation update. Please apply it to HEAD.
=
Euler Taveira de Oliveira
euler[at]yahoo_com_br
___
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http
Hi Bruce,
This is a small update for FAQ_brazilian.html. Don't forget to generate
the text version.
=
Euler Taveira de Oliveira
euler[at]yahoo_com_br
___
Yahoo! Acesso Grátis - Internet rápida e grátis.
These corrections against 8.0.0beta3 are for removal of the Tcl interface
from core. I found two left-over references in the top-level README to be
fixed, several in the top-level INSTALL and Installation chapter of the
manual (both generated from docs/src/sgml/installation.sgml, I think) and
one
Peter Eisentraut wrote:
Tom Lane wrote:
I found the following closely-related suggestion in the Make manual.
It's not quite there because it doesn't seem to provide a way to pass
down the current action (all/clean/install/etc) to the sub-Make.
Any ideas how we could do that?
I've seen the
Folks,
This patch clarifies the usage of references in PL/Perl :)
Cheers,
D
--
David Fetter [EMAIL PROTECTED] http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778
Remember to vote!
? plperl.diff
Index: doc/src/sgml/plperl.sgml
=
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I've seen the following idea somewhere:
Looks like you used a variant of this in src/backend/Makefile.
> Then again, the original proposal doesn't sound so bad either.
Well, I'd like a more generic fix that we could apply everywhere,
because right n
Tom Lane wrote:
> I found the following closely-related suggestion in the Make manual.
> It's not quite there because it doesn't seem to provide a way to pass
> down the current action (all/clean/install/etc) to the sub-Make.
> Any ideas how we could do that?
I've seen the following idea somewhere
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>>> If you run make installcheck in contrib it stops on the first module
>>> that fails. This is mildly annoying from the point of view of the
>>> buildfarm script, which wants to run all th
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
If you run make installcheck in contrib it stops on the first module
that fails. This is mildly annoying from the point of view of the
buildfarm script, which wants to run all the available regression tests.
Yeah. ISTM that "ma
Sergej Sergeev <[EMAIL PROTECTED]> writes:
>> What happens if you feed other pseudotypes, like cstring or
>> language_handler? Shouldn't that be disallowed or something?
> Other pseudo-types are disallowed (no-change)
No, because you diked out the check at lines 1452ff, rather than
upgrading it
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> What happens if you feed other pseudotypes, like cstring or
> language_handler? Shouldn't that be disallowed or something?
Indeed. This patch breaks those defenses...
regards, tom lane
---(end of broad
Alvaro Herrera wrote:
On Wed, Sep 29, 2004 at 07:13:47PM +0300, Sergej Sergeev wrote:
Patch provide support for array type and pseudo type
(anyelement, anyarray) for function parameters and result.
for example:
CREATE FUNCTION add_three_values(anyelement, anyelement, anyelement)
RETURNS anyel
On Wed, Sep 29, 2004 at 07:13:47PM +0300, Sergej Sergeev wrote:
> Patch provide support for array type and pseudo type
> (anyelement, anyarray) for function parameters and result.
> for example:
>
> CREATE FUNCTION add_three_values(anyelement, anyelement, anyelement)
> RETURNS anyelement AS '
>
Patch provide support for array type and pseudo type
(anyelement, anyarray) for function parameters and result.
for example:
CREATE FUNCTION add_three_values(anyelement, anyelement, anyelement)
RETURNS anyelement AS '
return $_[0]+$_[1]+$_[2];
' LANGUAGE plperl;
CREATE FUNCTION make_array(anyel
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> If you run make installcheck in contrib it stops on the first module
> that fails. This is mildly annoying from the point of view of the
> buildfarm script, which wants to run all the available regression tests.
Yeah. ISTM that "make -k installcheck
> > I was hoping this would be in for beta 3, but alas - can someone
> > *please* commit the win32 version patch at:
> > http://candle.pha.pa.us/mhonarc/patches/msg0.html
>
> Personally I was holding off in hopes of seeing a cleaner solution.
> A patch that requires every executable-building M
If you run make installcheck in contrib it stops on the first module
that fails. This is mildly annoying from the point of view of the
buildfarm script, which wants to run all the available regression tests.
To solve that I implemented a new target that does run them all and only
fails at the e
You know that many calendars exist in the world such as Japanese, Indian,
Hebrew, Persian(jalali), ... and no support of these calendars are
supported in postgresql.
The only calendar that is supported in postgresql, is "Gregorian". there
is no support in glibc for calendars in localization suppor
you know that many calendars exist in the world such as Japanese, Indian,
Hebrew, Persian(jalali), ... and no support of these calendars are
supported in postgresql.
the only calendar that is supported in postgresql, is "Gregorian".
there is no support in glibc for calendars in localization support
> > > So, here is a new patch. Summary:
> >
> > There is still a hard-coded python version in "libpython23.a".
>
> Argh. I thought I caught them all. How the heck did I miss
> such an obvious one.
> Of cuorse, it's supposed to be libpython${pytverstr}.a...
> Same for the .def file on the next l
22 matches
Mail list logo
