On Fri, Jun 08, 2012 at 11:32:40AM -0400, Robert Haas wrote:
> On Fri, Jun 1, 2012 at 11:48 AM, Bruce Momjian wrote:
> > Should this be back-patched? (Problem first reported in PG 9.1 due to
> > the removal of a backward-compatibility symlink.) I am not sure we have
> > had enough problem report
On Fri, Jun 1, 2012 at 11:48 AM, Bruce Momjian wrote:
> Should this be back-patched? (Problem first reported in PG 9.1 due to
> the removal of a backward-compatibility symlink.) I am not sure we have
> had enough problem reports to warrant it (3 reports).
We back-patch a lot of things based on
On Thu, May 31, 2012 at 09:37:06PM -0400, Bruce Momjian wrote:
> > I share Tom's caution on this, but I think we need to make sure we are
> > addressing any possible risk of an isolated pg_upgrade fix, now that we
> > understand the cause.
>
> FYI, this query will show any functions defined in the
On Thu, May 31, 2012 at 06:30:30PM -0400, Bruce Momjian wrote:
> > Hm, I'm not sure about that. The general charter of pg_dump is to
> > produce a dump that will replicate the state of the database.
> > Editorializing on it in order to make it more likely to reload in a
> > different version of PG
On 05/31/2012 03:30 PM, Bruce Momjian wrote:
On Thu, May 31, 2012 at 06:24:04PM -0400, Tom Lane wrote:
Hm, I'm not sure about that. The general charter of pg_dump is to
produce a dump that will replicate the state of the database.
Editorializing on it in order to make it more likely to reloa
On Thu, May 31, 2012 at 06:24:04PM -0400, Tom Lane wrote:
> Adrian Klaver writes:
> > On 05/31/2012 11:53 AM, Bruce Momjian wrote:
> >> On Tue, May 29, 2012 at 10:34:16PM -0400, Bruce Momjian wrote:
> >> OK, so what do people want me to do on this? Apply my pg_upgrade fix or
> >> go for a more ge
Adrian Klaver writes:
> On 05/31/2012 11:53 AM, Bruce Momjian wrote:
>> On Tue, May 29, 2012 at 10:34:16PM -0400, Bruce Momjian wrote:
>> OK, so what do people want me to do on this? Apply my pg_upgrade fix or
>> go for a more general fix that will prevent pg_dump from dumping out
>> these duplic
On 05/31/2012 11:53 AM, Bruce Momjian wrote:
On Tue, May 29, 2012 at 10:34:16PM -0400, Bruce Momjian wrote:
OK, so what do people want me to do on this? Apply my pg_upgrade fix or
go for a more general fix that will prevent pg_dump from dumping out
these duplicate functions --- it would invo
On Tue, May 29, 2012 at 10:34:16PM -0400, Bruce Momjian wrote:
> My point is that plpython_call_handler is defined in the public and
> pg_catalog schema, as are other language handlers.
>
> In fact, an argument could be made that the bug is really in pg_dump.
> When we moved the language handlers
On Tue, May 29, 2012 at 07:13:24PM -0700, Adrian Klaver wrote:
> >This moved the helper functions into pg_catalog, but the author probably
> >didn't realize that public schema helper functions would continue to be
> >dumped by pg_dump. These helper functions continued to be
> >dumped/restored unti
On 05/29/2012 05:44 PM, Bruce Momjian wrote:
On Sun, May 27, 2012 at 11:49:31AM -0700, Adrian Klaver wrote:
If you can help me find out how these got defined this way, I might be
able to prevent this problem for the next person.
After reading the above thread here is what the queries mention
On Sun, May 27, 2012 at 11:49:31AM -0700, Adrian Klaver wrote:
> >
> > If you can help me find out how these got defined this way, I might be
> > able to prevent this problem for the next person.
> >
>
> After reading the above thread here is what the queries mentioned return:
>
> production=#
On 05/27/2012 01:35 PM, Tom Lane wrote:
Adrian Klaver writes:
After reading the above thread here is what the queries mentioned return:
production=# SELECT nspname,proname,probin FROM pg_proc,pg_namespace
WHERE probin LIKE '%python%' and pg_proc.pronamespace=pg_namespace.oid;
nspname |
On 05/27/2012 01:35 PM, Tom Lane wrote:
Adrian Klaver writes:
After reading the above thread here is what the queries mentioned return:
production=# SELECT nspname,proname,probin FROM pg_proc,pg_namespace
WHERE probin LIKE '%python%' and pg_proc.pronamespace=pg_namespace.oid;
nspname |
Adrian Klaver writes:
> After reading the above thread here is what the queries mentioned return:
> production=# SELECT nspname,proname,probin FROM pg_proc,pg_namespace
> WHERE probin LIKE '%python%' and pg_proc.pronamespace=pg_namespace.oid;
> nspname | proname | probin
On 05/26/2012 07:24 PM, Bruce Momjian wrote:
> On Sat, May 26, 2012 at 11:42:09PM +, adrian.kla...@gmail.com wrote:
>> The following bug has been logged on the website:
>>
>> Bug reference:
>> Logged by: Adrian Klaver
>> Email address: adrian.kla...@gmail.com
>> PostgreS
On Sat, May 26, 2012 at 11:42:09PM +, adrian.kla...@gmail.com wrote:
> The following bug has been logged on the website:
>
> Bug reference:
> Logged by: Adrian Klaver
> Email address: adrian.kla...@gmail.com
> PostgreSQL version: 9.0.7
> Operating system: Linux/OpenSu
17 matches
Mail list logo
