Am 11.06.2010 21:19, schrieb Robert Haas:
On Fri, Jun 11, 2010 at 2:46 PM, Dimitri Fontaine
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
Top posting, sorry for that.
--
dim
Le 10 juin 2010 à 03:40, Robert Haas robertmh...@gmail.com a écrit :
On Wed, Jun 9, 2010 at 9:35 PM, Bruce Momjian br...@momjian.us
wrote:
Robert Haas wrote:
I think users would rather have the restore fail, and know right
away
they have an issue,
On Fri, Jun 11, 2010 at 2:46 PM, Dimitri Fontaine
dfonta...@hi-media.com 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
Stephen Frost sfr...@snowman.net 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
Robert Haas robertmh...@gmail.com 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
Hartmut Goebel wrote:
re. 1): While this may be true for many applications it is using
hand-crafted SQL statements, it is plain wrong for all applications
using some abstraction layer. These layers need to quote column
names anyway and the application does not need to be changed here
at
Am 10.06.2010 03:10, schrieb Bruce Momjian:
The point is that if WINDOW was not a reserved word in 8.3 but is in
8.4, then every reference to a user column of WINDOW in any 8.4
application will need to be double-quoted, and odds are the user did not
do that in 8.3.
This argument is like: We
Am 05.06.2010 22:02, schrieb Dimitri Fontaine:
Alvaro Herrera alvhe...@commandprompt.com writes:
I don't think dumps must be human-readable is an argument to reject
such a switch, as long as it's off by default. And I haven't seen any
other valid argument either, so +1 from me.
Well as
Am 07.06.2010 02:32, schrieb Robert Haas:
But we will likely add more
keywords at some point in the future, and while providing an output
format that quotes everything won't fix every potential problem, it
might make life easier for some people.
+10
Exactly my point: Make life easier for
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
Robert Haas wrote:
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.)
Eeh, I've had this happen to me on earlier releases, and it didn't
feel
Hartmut Goebel wrote:
Am 07.06.2010 02:32, schrieb Robert Haas:
But we will likely add more
keywords at some point in the future, and while providing an output
format that quotes everything won't fix every potential problem, it
might make life easier for some people.
+10
Exactly my point:
On Thu, Jun 10, 2010 at 9:02 AM, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc 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
Robert Haas wrote:
On Thu, Jun 10, 2010 at 9:02 AM, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc 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
On Thu, Jun 10, 2010 at 15:35, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc wrote:
Robert Haas wrote:
On Thu, Jun 10, 2010 at 9:02 AM, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc wrote:
I for myself would be rather annoyed if we started quoting all column
names
in our dumps. This is
Stefan Kaltenbrunner 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
Magnus Hagander wrote:
On Thu, Jun 10, 2010 at 15:35, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc wrote:
Robert Haas wrote:
On Thu, Jun 10, 2010 at 9:02 AM, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc wrote:
I for myself would be rather annoyed if we started quoting all column
Robert Haas wrote:
On Thu, Jun 10, 2010 at 9:35 AM, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc 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
* Magnus Hagander (mag...@hagander.net) wrote:
On Thu, Jun 10, 2010 at 15:35, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc wrote:
that will pretty much defeat the purpose for most use cases i guess because
people will dump with the defaults and only discover the problem after the
fact.
Bruce Momjian br...@momjian.us writes:
From a code perspective, the difficulting in adding such a flag is that
much of the quoting happens inside the backend, not by pg_dump, and
therefore there is significant code change required to add this flag.
Yeah, and not only that, but you'd need the
Stephen Frost wrote:
* Magnus Hagander (mag...@hagander.net) wrote:
On Thu, Jun 10, 2010 at 15:35, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc wrote:
that will pretty much defeat the purpose for most use cases i guess because
people will dump with the defaults and only discover the problem
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes:
That is exactly what I think is to big a promise - I don't think we
can actually guarantee that this will fix the dump/restore issue (well
the dump might load but say the 3 lines of plpgsql using dynamic SQL
will still be broken).
* Bruce Momjian (br...@momjian.us) wrote:
From a code perspective, the difficulting in adding such a flag is that
much of the quoting happens inside the backend, not by pg_dump, and
therefore there is significant code change required to add this flag.
So, that strikes me as the main argument
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
Well, if you dump in custom format, it could be useful to be able to
do this on pg_restore time. Not having followed this thread in detail,
but would that work? That would be a much more useful option...
I don't think so because much of
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes:
That is exactly what I think is to big a promise - I don't think we
can actually guarantee that this will fix the dump/restore issue (well
the dump might load but say the 3 lines of plpgsql
Stephen Frost sfr...@snowman.net writes:
We're talking about a quote-everything option, not what quote_ident()
does today. I don't see why that needs to be done by the backend or why
pg_dump/pg_restore doesn't have enough info to handle that.
Are you proposing to stick a SQL parser into
Stephen Frost sfr...@snowman.net writes:
Erm, I don't know that we deal with function-body problems today, even
when using the newer version of pg_dump, do we?
Right, any forward-compatibility problems arising inside functions
are strictly the user's to deal with, and always have been.
So
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
Erm, I don't know that we deal with function-body problems today, even
when using the newer version of pg_dump, do we?
Right, any forward-compatibility problems arising inside functions
are strictly the user's
Stephen Frost sfr...@snowman.net writes:
To this point, and perhaps to the other regarding VIEW definitions to
some extent, while the solution would move us from 80% to 90% of things
in PG that might cause a restore from an older pg_dump to fail, I think
another metric we should consider is %
Excerpts from Bruce Momjian's message of mié jun 09 21:35:57 -0400 2010:
Alvaro Herrera wrote:
Excerpts from Bruce Momjian's message of mi\xc3\xa9 jun 09 21:10:21 -0400
2010:
I think users would rather have the restore fail, and know right away
they have an issue, than to do the
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,
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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.
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
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
* Stefan Kaltenbrunner (ste...@kaltenbrunner.cc) wrote:
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
Stephen Frost sfr...@snowman.net writes:
Perhaps we should have a 'multi-file' option with a 'base-file-name'
parameter which then generates:
pre-data DDL
data
post-data DDL
psql script to run them in order (\i-style)
Actually, I was thinking that the three-file approach is just
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Actually, I was thinking that the three-file approach is just
unnecessary complication. What about two files, schema and data,
with the schema file including a \i for the data at the right place?
This could be enabled by a single additional switch
On Thu, Jun 10, 2010 at 10:25 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
From a code perspective, the difficulting in adding such a flag is that
much of the quoting happens inside the backend, not by pg_dump, and
therefore there is significant code change
Am 10.06.2010 13:46, schrieb Kevin Grittner:
I have a feeling that many here don't understand how ubiquitous such
frameworks are.
I got his impression, too. :-(
Our programmers have no way to get a statement to
the database from within the application *without* all identifiers
being
Am 10.06.2010 03:35, schrieb Bruce Momjian:
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,
Am 10.06.2010 15:48, schrieb Robert Haas:
Maybe so, but I don't give either method high marks for convenience.
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. What
our current policy essentially means is that I
Am 10.06.2010 17:01, schrieb Tom Lane:
Um, I rather doubt that experience level has much of anything to do with
one's probability of getting blindsided by new SQL syntax.
Please stop expecting the one doing the upgrade has a lot of knowledge
at all. He is just the one pointed out to perform
Am 10.06.2010 17:23, schrieb Heikki Linnakangas:
Much easier to do a schema-only dump, edit that, and dump data separately.
I tries this in my very case. Did not work due sequences, triggers and
primary keys. I ended up editing a 500 MB file in vi.
--
Schönen Gruß - Regards
Hartmut Goebel
Robert Haas wrote:
On Sun, Jun 6, 2010 at 2:53 PM, Dimitri Fontaine dfonta...@hi-media.com
wrote:
Robert Haas robertmh...@gmail.com writes:
Well as Bruce said this option won't solve the OP's problem, unless the
application he's using for managing the backups do use the option.
Well,
On Wed, Jun 9, 2010 at 9:10 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Sun, Jun 6, 2010 at 2:53 PM, Dimitri Fontaine dfonta...@hi-media.com
wrote:
Robert Haas robertmh...@gmail.com writes:
Well as Bruce said this option won't solve the OP's problem, unless the
Excerpts from Bruce Momjian's message of mié jun 09 21:10:21 -0400 2010:
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.
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
Alvaro Herrera wrote:
Excerpts from Bruce Momjian's message of mi?? jun 09 21:10:21 -0400 2010:
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
On Wed, Jun 9, 2010 at 9:35 PM, Bruce Momjian br...@momjian.us 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
On Jun 5, 2010, at 4:02 PM, Dimitri Fontaine dfonta...@hi-media.com
wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
I don't think dumps must be human-readable is an argument to reject
such a switch, as long as it's off by default. And I haven't seen
any
other valid argument
Robert Haas robertmh...@gmail.com writes:
Well as Bruce said this option won't solve the OP's problem, unless the
application he's using for managing the backups do use the option.
Well, that's a pretty trivial change to the backup script. +1 from me on
providing a pg_dump option.
The
On Sun, Jun 6, 2010 at 2:53 PM, Dimitri Fontaine dfonta...@hi-media.com wrote:
Robert Haas robertmh...@gmail.com writes:
Well as Bruce said this option won't solve the OP's problem, unless the
application he's using for managing the backups do use the option.
Well, that's a pretty trivial
Robert Haas robertmh...@gmail.com writes:
I think as a community we can sometimes be a bit intolerant of people
who don't do things exactly the right way and get themselves into
trouble.
Casting aside the sweeping generalizations for a moment ... this is
about how much effort we are willing to
Alvaro Herrera alvhe...@commandprompt.com writes:
I don't think dumps must be human-readable is an argument to reject
such a switch, as long as it's off by default. And I haven't seen any
other valid argument either, so +1 from me.
Well as Bruce said this option won't solve the OP's problem,
Am 03.06.2010 16:15, schrieb Tom Lane:
Solution: pg_dump should quote *all* column-names, no matter if they are
keywords or not.
That was considered and rejected long ago. Readability of the dump
script is something that we put a nonzero value on.
Sorry, I do not understand this.
I
Am 03.06.2010 20:07, schrieb Tom Lane:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Hartmut Goebel h.goe...@goebel-consult.de wrote:
If upgraded the rpm-packages from 8.3 to 8.4. Then postgres failed
starting (something like Database version mismatch).
You need to be running the old
* Hartmut Goebel (h.goe...@goebel-consult.de) wrote:
Am 03.06.2010 16:15, schrieb Tom Lane:
That was considered and rejected long ago. Readability of the dump
script is something that we put a nonzero value on.
I assume you mean readability for humans?!
Yes, readability for humans is
* Hartmut Goebel (h.goe...@goebel-consult.de) wrote:
Am 04.06.2010 13:56, schrieb Stephen Frost:
Quoting all column names makes the dump script much more difficult for
human consumption, which is important.
I don't agree with you here. But this may be a matter of personal taste.
Esp. I
Am 04.06.2010 13:56, schrieb Stephen Frost:
Quoting all column names makes the dump script much more difficult for
human consumption, which is important.
I don't agree with you here. But this may be a matter of personal taste.
Esp. I think, functionality is much ore important than a small
Am 04.06.2010 14:57, schrieb Stephen Frost:
* Hartmut Goebel (h.goe...@goebel-consult.de) wrote:
Am 04.06.2010 13:56, schrieb Stephen Frost:
Quoting all column names makes the dump script much more difficult for
human consumption, which is important.
I don't agree with you here. But this may
Hartmut Goebel h.goe...@goebel-consult.de wrote:
The application already quotes all column names :-) It's using a
generic framework which does not (and must not) rely on column
names being non-keywords.
Same here. I suspect that this is much more commonn than many
PostgreSQL developers
Kevin Grittner wrote:
Hartmut Goebel h.goe...@goebel-consult.de wrote:
The application already quotes all column names :-) It's using a
generic framework which does not (and must not) rely on column
names being non-keywords.
Same here. I suspect that this is much more commonn than
On Fri, Jun 04, 2010 at 02:59:48PM -0400, Bruce Momjian wrote:
Kevin Grittner wrote:
Hartmut Goebel h.goe...@goebel-consult.de wrote:
The application already quotes all column names :-) It's using a
generic framework which does not (and must not) rely on column
names being
David Fetter da...@fetter.org wrote:
It seems like something that's doable by pg_dump as a default
off option. TODO for 9.1?
Sounds good to me.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
David Fetter wrote:
On Fri, Jun 04, 2010 at 02:59:48PM -0400, Bruce Momjian wrote:
Kevin Grittner wrote:
Hartmut Goebel h.goe...@goebel-consult.de wrote:
The application already quotes all column names :-) It's using a
generic framework which does not (and must not) rely on
--On 4. Juni 2010 15:19:42 -0400 Bruce Momjian br...@momjian.us wrote:
That would make the bug go away,
rather than require users to use a special flag (and find out only after
they were doing the reload).
Out of curiosity, why is this a bug now? We recommend migration
procedures always to
Bernd Helmle maili...@oopsware.de writes:
Out of curiosity, why is this a bug now?
It isn't...
And wouldn't introducing backpatching such behavorial changes to pg_dump
violate our policy in *not* to change such things in minor releases?
That was just an off-the-cuff idea, it has certainly
Excerpts from Kevin Grittner's message of vie jun 04 14:53:17 -0400 2010:
Same here. I suspect that this is much more commonn than many
PostgreSQL developers realize; and I think it makes a reasonable
case for at least an *option* to quote all identifiers emitted by
pg_dump.
I don't think
The following bug has been logged online:
Bug reference: 5488
Logged by: Hartmut Goebel
Email address: h.goe...@goebel-consult.de
PostgreSQL version: 8.3 / 8.4
Operating system: all
Description:pg_dump does not quote column names - pg_restore may
fail when upgrading
Hartmut Goebel h.goe...@goebel-consult.de wrote:
Description:pg_dump does not quote column names -
pg_restore may fail when upgrading
If a 8.3 table contains a column named window, the dump can not
be restored into a 8.4 database. Reasons: a) window is a new
Hartmut Goebel h.goe...@goebel-consult.de writes:
If a 8.3 table contains a column named window, the dump can not be
restored into a 8.4 database. Reasons: a) window is a new keyword in 8.4
b) pg_dump does not quote column names.
This is one of the cases where it's helpful to use the newer
Hartmut Goebel h.goe...@goebel-consult.de wrote:
I dumped with the executable form 8.3.
That's not expected to work for an upgrade to 8.4.
8.4 did not allow accessing the 8.3 database
What do you mean? (What did you try and what happened?)
-Kevin
--
Sent via pgsql-bugs mailing list
Am 03.06.2010 15:43, schrieb Kevin Grittner:
Note that the documentation recommends always running pg_dump using
the executable from the target version, not the source version. Are
you using the pg_dump executable from 8.4?
I dumped with the executable form 8.3.
8.4 did not allow accessing
Am 03.06.2010 16:16, schrieb Kevin Grittner:
8.4 did not allow accessing the 8.3 database
What do you mean? (What did you try and what happened?)
If upgraded the rpm-packages from 8.3 to 8.4. Then postgres failed
starting (something like Database version mismatch). So I downgraded
to 8.3,
Hartmut Goebel h.goe...@goebel-consult.de wrote:
If upgraded the rpm-packages from 8.3 to 8.4. Then postgres failed
starting (something like Database version mismatch).
You need to be running the old server using 8.3 software and while
using pg_dump from 8.4 software. Does your packager
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Hartmut Goebel h.goe...@goebel-consult.de wrote:
If upgraded the rpm-packages from 8.3 to 8.4. Then postgres failed
starting (something like Database version mismatch).
You need to be running the old server using 8.3 software and while
On Thu, Jun 03, 2010 at 06:04:16PM +0200, Hartmut Goebel wrote:
If upgraded the rpm-packages from 8.3 to 8.4. Then postgres failed
starting (something like Database version mismatch). So I downgraded
to 8.3, pg_dump'ed there, upgraded and pg_restore'd.
pg_dump will complain if its version
76 matches
Mail list logo
