Hello.
I noticed what I think is a bug in pg_dump.
When dumping foreign tables, the server name is not properly quoted,
which leads to unrestorable dumps.
eg, a foreign table attached to a foreign server named "file-test" is
dumped as:
CREATE FOREIGN TABLE "test-table" (
col1 integer
)
SERV
Hello Craig,
thanks for your answer.
> Restore using PgAdmin III or using a unicode console.
> This is a limitation of using a Win1252 client encoding when restoring
> data that isn't restricted to Win1252 and cannot be fixed directly.
That's new to me. AFAIK pg_restore looks int
Ronan Dunklau writes:
> When dumping foreign tables, the server name is not properly quoted,
> which leads to unrestorable dumps.
Clearly a bug.
> Please look at the attached test case and the proposed patch.
I think this patch is not in keeping with typical coding practices in
pg_dump. Usuall
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thanks for the response.
How will this bug be handled with regards to releases ?
If the fix is going to take a while to be released, we could rename
our servers to valid names but we would prefer not to.
Regards,
- --
Ronan Dunklau
-BEGIN PGP
I stumbled upon this situation when playing with extension upgrades.
The problem I was having was that auto-generated datatypes were also
being added to the extension and it wasn't obvious this was happening.
I know this has been changed in 9.1 stable and in master.
What happened was that I was ab
Ronan Dunklau writes:
> How will this bug be handled with regards to releases ?
It'll be fixed in next week's releases.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mail
Phil Sorber writes:
> I stumbled upon this situation when playing with extension upgrades.
> The problem I was having was that auto-generated datatypes were also
> being added to the extension and it wasn't obvious this was happening.
> I know this has been changed in 9.1 stable and in master.
I
On Mon, Nov 28, 2011 at 3:12 PM, Tom Lane wrote:
> Phil Sorber writes:
>> I stumbled upon this situation when playing with extension upgrades.
>> The problem I was having was that auto-generated datatypes were also
>> being added to the extension and it wasn't obvious this was happening.
>> I kno
Phil Sorber writes:
> I am still able to reproduce the "ERROR: cache lookup failed for extension
> x" if I use an explicit 'drop extension'. I am unsure how I can
> reverse the state it is now in. I assume there is some system catalog
> I can edit that will fix it?
I think you have some dang
On Mon, Nov 28, 2011 at 4:10 PM, Tom Lane wrote:
> Phil Sorber writes:
>> I am still able to reproduce the "ERROR: cache lookup failed for extension
>> x" if I use an explicit 'drop extension'. I am unsure how I can
>> reverse the state it is now in. I assume there is some system catalog
>>
On Mon, Nov 28, 2011 at 6:02 PM, Simon Riggs wrote:
> On Fri, Nov 25, 2011 at 6:33 PM, Tom Lane wrote:
> > Maxim Boguk writes:
> >> I know GIST on intarray[] do not have that problem.
> >> Very likely the problem is limited to intarray[] GIN indexes only
> >> (but I going to test some other not
Phil Sorber writes:
> I compiled 9.1 stable head and tested it out. You are correct my
> example no longer works there because of the patch that stopped the
> auto-generated types from becoming dependencies of the extension. In
> fact, the cascade no longer works even if I don't remove the table o
David Schnur writes:
> I probably can't get a stack trace, but I was able to reproduce it with
> just that function. Without the function, pg_dump works fine. I can DROP
> the function, pg_dump works, then add it back again and pg_dump crashes.
Hmph. I still can't reproduce this here, which se
Maxim Boguk writes:
> Is that fix will be included to the next minor versions releases?
Yes, it's in already:
http://git.postgresql.org/gitweb/?p=postgresql.git
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your sub
On 11/28/2011 08:26 PM, Thomas Goerner wrote:
Hello Craig,
thanks for your answer.
> Restore using PgAdmin III or using a unicode console.
> This is a limitation of using a Win1252 client encoding when restoring
> data that isn't restricted to Win1252 and cannot be fixed directly.
That's ne
15 matches
Mail list logo