Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group