[BUGS] Re: BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
On 2010-06-10, Robert Haas wrote: > On Thu, Jun 10, 2010 at 9:02 AM, Stefan Kaltenbrunner > wrote: >> I for myself would be rather annoyed if we started quoting all column names >> in our dumps. This is seriously hampering readability and while it is >> already annoying that pg_dump output is slightly different from the original >> DDL used this would make it far worse. > > It's only been proposed to make it an option, not to shove it down > anyone's throat. > > Given Tom's comments upthread, I suspect that much of this will come > down to whether anyone feels like trying to put in the work to make > this happen, and whether they can come up with a reasonably clean > design that doesn't involve massive code changes. Having not studied > the problem, I don't have an opinion on whether that's possible. > > I do agree that the human readability of pg_dump is an asset in many > situations - I have often dumped out the DDL for particular objects > just to look at it, for example. However, I emphatically do NOT agree > that leaving someone with a 500MB dump file (or, for some people on > this list, a whole heck of a lot larger than that) that has to be > manually edited to reload is a useful behavior. It's a huge pain in > the neck. Don't edit manually, use sed instead. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Re: BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
On 2010-06-10, Stefan Kaltenbrunner wrote: > Tom Lane wrote: >> Heikki Linnakangas writes: >>> On 10/06/10 16:21, Robert Haas wrote: I do agree that the human readability of pg_dump is an asset in many situations - I have often dumped out the DDL for particular objects just to look at it, for example. However, I emphatically do NOT agree that leaving someone with a 500MB dump file (or, for some people on this list, a whole heck of a lot larger than that) that has to be manually edited to reload is a useful behavior. It's a huge pain in the neck. >> >>> Much easier to do a schema-only dump, edit that, and dump data separately. >> >> That gets you out of the huge-file-to-edit problem, but the performance >> costs of restoring a separate-data dump are a pretty serious >> disadvantage. We really should do something about that. > > well that is an argument for providing not only --schema-only and > --data-only but rather three options one for the table definitions, one > for the data and one for all the constraints and indexes. So basically > what pg_dump is currently doing anyway but just exposed as flags. You can extract those parts from a schema-only (or full) dump using sed or you can just edit the schema-only dump and insert \i datadump.sql in the apropriate spot. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5499: SQL syntax bug
The following bug has been logged online: Bug reference: 5499 Logged by: Curtis Stecke Email address: cste...@interlegis.com PostgreSQL version: 8.4 Operating system: Windows Xp Description:SQL syntax bug Details: Inserting text that starts with or ends with a dollar sign ($) is impossible. Documentation is not clear on how to do this as well. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5499: SQL syntax bug
"Curtis Stecke" wrote:
> Inserting text that starts with or ends with a dollar sign ($) is
> impossible. Documentation is not clear on how to do this as well.
Works for me. Care to give an example of your problem?
test=# create table t1 (c1 text);
CREATE TABLE
test=# insert into t1 values ('$sometext');
INSERT 0 1
test=# insert into t1 values ('sometext$');
INSERT 0 1
test=# insert into t1 values ('$sometext$');
INSERT 0 1
test=# select * from t1;
c1
$sometext
sometext$
$sometext$
(3 rows)
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
Top posting, sorry for that. -- dim Le 10 juin 2010 à 03:40, Robert Haas a écrit : On Wed, Jun 9, 2010 at 9:35 PM, Bruce Momjian wrote: Robert Haas wrote: I think users would rather have the restore fail, and know right away they have an issue, than to do the upgrade, and find out later that some of their application queries fail and they need to run around fixing them. ?(FYI, pg_upgrade would use the new pg_dump and would not fail.) In a way, the fact that the restore fails can be seen as a feature --- they get the error before the go live on 8.4. ?(Yeah, I am serious.) +1 Eeh, I've had this happen to me on earlier releases, and it didn't feel like a feature to me. YMMV, of course. Would you have preferred later application failure? YES! It's a heck of a lot easier to fix the application than it is to doctor the dump output with vi. But of course you don't ever do that. What you do once the restore failed on you is fix the schema and the application before to upgrade. At least you have a chance to upgrade to a working setup. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
On Fri, Jun 11, 2010 at 2:46 PM, Dimitri Fontaine wrote: Eeh, I've had this happen to me on earlier releases, and it didn't feel like a feature to me. YMMV, of course. >>> >>> Would you have preferred later application failure? >> >> YES! It's a heck of a lot easier to fix the application than it is to >> doctor the dump output with vi. > > But of course you don't ever do that. What you do once the restore failed on > you is fix the schema and the application before to upgrade. Presumably, you mean that YOU don't ever do that. What everybody else does is up to them, and there are plenty of people on this thread saying either (1) they don't want to do what you're proposing or (2) their application doesn't need fixing because it already quotes everything. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
Stephen Frost writes: > If it's an option w/ a default of "off", then chances are the admin will > get the failure you're talking about, realize there's an issue, but then > have a way to actually *fix* the restore without having to hack up > multi-gigabyte files using vi. If you'd like, you're welcome to > consider the default of "off" as a feature. > > +1 from me for adding the option. +1 too. Seems I've been unclear, my thinking is that this option is not a solution for everyone, but I do agree that it will help in some cases. And in those cases you'll be so happy to have it! Regards, -- dim -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5500: SPI_execute_plan_with_paramlist SPI_ERROR_TRANSACTION with savepoint
The following bug has been logged online: Bug reference: 5500 Logged by: Robert Walker Email address: robwalke...@speedymail.org PostgreSQL version: 9.0 beta 2 Operating system: Windows XP 32-bit SP2 Description:SPI_execute_plan_with_paramlist SPI_ERROR_TRANSACTION with savepoint Details: SPI_execute_plan_with_paramlist seems to be newly introduced into 9.0 beta that is causing an error in pl/pgsql when attempting to create a savepoint. This did not happen when using version 8.4 (which I assume was not using SPI_execute_plan_with_paramlist), so I believe this is a regression. The specific format of the error is: ERROR: SPI_execute_plan_with_paramlist failed executing query "SAVEPOINT savepoint_name": SPI_ERROR_TRANSACTION SQL state: XX000 Context: PL/pgSQL function "add_foo" line 241 at SQL statement Before the savepoint is only a couple of statements: one insert statement and another insert statement using "returning *" into a variable. The function parameters use %TYPE in order to help ensure the parameters match the same type as the table column it is meant to deal with. The function's return value is a rowtype of the results from the insert/returning right before the savepoint. If I comment out the few lines regarding savepoints, the function works (but without error trapping of course), so I know it's not a syntax error or some other type of error. PostgreSQL for some reason wants to use SPI_execute_plan_with_paramlist and this causes the error. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
Robert Haas writes: > Suppose I have a server running 8.2 and I'm going to wipe it and > install the latest version of $DISTRIBUTION which bundles 8.4. [...] > I'm sure someone will tell me my system administration practices suck, > but people do these kinds of things, in real life, all the time. > Maybe if we all had an IQ of 170 and an infinite hardware budget we > wouldn't, but my IQ is only 169. :-) So why aren't you using a distribution that ease the pain by supporting exactly your use case? :) Regards, -- dim -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5500: SPI_execute_plan_with_paramlist SPI_ERROR_TRANSACTION with savepoint
"Robert Walker" writes: > SPI_execute_plan_with_paramlist seems to be newly introduced into 9.0 beta > that is causing an error in pl/pgsql when attempting to create a savepoint. > This did not happen when using version 8.4 (which I assume was not using > SPI_execute_plan_with_paramlist), so I believe this is a regression. Um, it's never been the case that you could execute a SAVEPOINT statement inside plpgsql. I'd be interested to see the case that you claim worked in 8.4. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5500: SPI_execute_plan_with_paramlist SPI_ERROR_TRANSACTION with savepoint
Excerpts from Robert Walker's message of vie jun 11 14:49:03 -0400 2010: > SPI_execute_plan_with_paramlist seems to be newly introduced into 9.0 beta > that is causing an error in pl/pgsql when attempting to create a savepoint. > This did not happen when using version 8.4 (which I assume was not using > SPI_execute_plan_with_paramlist), so I believe this is a regression. > > The specific format of the error is: > > ERROR: SPI_execute_plan_with_paramlist failed executing query "SAVEPOINT > savepoint_name": SPI_ERROR_TRANSACTION If it fails to fail on 8.4, that's a bug -- it is *supposed* not to work. If you want to use savepoints in plpgsql you need to use EXCEPTION blocks. Can you provide a working example in 8.4? -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5501: PostgreSQL JDBC Driver has inappropriate import
The following bug has been logged online: Bug reference: 5501 Logged by: Dave Jarvis Email address: thanga...@gmail.com PostgreSQL version: 8.4.4 Operating system: Linux Description:PostgreSQL JDBC Driver has inappropriate import Details: PROBLEM postgresql-jdbc-8.4-701.src/org/postgresql/gss/MakeGSS.java:21: package com.sun.security.auth.callback does not exist [javac] import com.sun.security.auth.callback.TextCallbackHandler; [javac] ^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 1 error SOLUTION Remove the import line (the class is not used). You should not rely on Sun's internal packages. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
