Re: Not valid dump [8.2.9, 8.3.1]

From: "Gaetano Mendola" <mendola(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "Patrizia Grasso - Eutelsat" <pgrasso(at)mbigroup(dot)it>
Subject: Re: Not valid dump [8.2.9, 8.3.1]
Date: 2008-06-21 12:44:51
Message-ID: fb6a78870806210544k7ca3b444n7ff2608342b95826@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jun 20, 2008 at 4:37 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Gaetano Mendola <mendola(at)gmail(dot)com> writes:
> > we have faced lately dumps not valid, the bug can be replicated using a
> 8.2.9 or
> > a 8.3.1 server.
>
> > These are the steps to create the database that will generate a not valid
> dump:
>
> This is a bug in your function: it will not work if the search path
> doesn't contain the public schema. You'd be best advised to make it
> qualify the reference to t_public explicitly.

Yes, that's the way we are fixing it. Still I have a bitter taste being able
to
create a working database instance that doesn't generate a valid dump.

(Of course you realize that referencing any table at all in an
> "immutable" function is probably a mortal sin...)
>

Yes Tom I know, in our case that table is a lookup table, noone update,
delete, insert data in it, so from my point of view it is like I have
declared a
static array inside the function declaration.

--
cpp-today.blogspot.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2008-06-21 13:30:10 Re: -head build error report
Previous Message Andrew Dunstan 2008-06-21 11:53:48 Re: -head build error report