Re: [BUGS] pg_restore ignores -C when using a restore list -L
On 15/05/10 05:15, Alvaro Herrera wrote: > Excerpts from Tom Lane's message of vie may 14 13:26:06 -0400 2010: > > >> However, I think -C is a special case because it's quite un-obvious >> to the user that it effectively acts as a filter switch --- in fact a >> de-filtering switch, because the lack of -C is what filters out the >> DATABASE item. >> >> I'm inclined to think that we should document that the output of -l >> is restricted by -n and similar switches, but change the code so that >> -C doesn't affect -l output. Comments? >> > +1 > Was this discussed change made? Was it backported, or only applied to head? Thanks Russell -- 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
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 all. I have a feeling that many here don't understand how ubiquitous such frameworks are. Our programmers have no way to get a statement to the database from within the application *without* all identifiers being quoted. On the other hand, my conversion software has always been a command line with pg_dump piped to psql. (We are making our first test of Bruce's new techniques this week, though.) -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
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 do not need to fix the flat tire. I'm sure the engine is broken, too, so the driver can not drive anyway." Or to say it differently: IMHO your arguments are wrong in three points: 1) You make assumptions about the application bot quoting column names. 2) You are assuming the database maintainer is using an "self developed" application. 3) You are taking these assumptions as an excuse not to fix your part of the job. 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 all. re. 2): Simply consider the case where the application is developed by some third party (e.g. some open source project). The application developers already did change the application to work with. So this part of the job is already done. re 3): This is plain finger pointing: "Look, there are other issued to be fixed. No need to fix ours." For me these leaves a horrible impression about the Postgresql community: bone-head dogmatic tech-geeks, not willed to make the administrators live easier. > 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.) "Be happy that I shot you, you would have starved anyway." Gnaa! -- Schönen Gruß - Regards Hartmut Goebel Dipl.-Informatiker (univ.), CISSP, CSSLP Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de Monatliche Kolumne: http://www.cissp-gefluester.de/ Goebel Consult mit Mitglied bei http://www.7-it.de smime.p7s Description: S/MIME Cryptographic Signature
Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
Am 05.06.2010 22:02, schrieb Dimitri Fontaine: > Alvaro Herrera 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, unless the > application he's using for managing the backups do use the option. As I already wrote, this would solve my problem. The application uses a generic framework which quotes all column names (and such) automatically. Esp. this would solve the problem for *all other users* of this application, too. And as I already wrote, too, most of these users/administrators are not database gurus. They need as much support as possible to make their live easier. -- Schönen Gruß - Regards Hartmut Goebel Dipl.-Informatiker (univ.), CISSP, CSSLP Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de Monatliche Kolumne: http://www.cissp-gefluester.de/ Goebel Consult mit Mitglied bei http://www.7-it.de smime.p7s Description: S/MIME Cryptographic Signature
Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
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 others. Admins have a hard job anyway. BTW: mysql does a far better job here. -- Schönen Gruß - Regards Hartmut Goebel Dipl.-Informatiker (univ.), CISSP, CSSLP Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de Monatliche Kolumne: http://www.cissp-gefluester.de/ Goebel Consult mit Mitglied bei http://www.7-it.de smime.p7s Description: S/MIME Cryptographic Signature
Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
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 like a feature to me. YMMV, of course. > > Would you have preferred later application failure? 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. Thanks, Stephen signature.asc Description: Digital signature
Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
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: Make life easier for others. Admins have a hard job anyway. 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. I'm also not convinced that this is a good idea at all, using keywords like that is always an issue and forward portability of dumps in general is imho a pipe dream BTW: mysql does a far better job here. not sure I agree here but well... Stefan -- 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 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. -- 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] pg_restore ignores -C when using a restore list -L
On Thu, Jun 10, 2010 at 3:58 AM, Russell Smith wrote: > On 15/05/10 05:15, Alvaro Herrera wrote: >> Excerpts from Tom Lane's message of vie may 14 13:26:06 -0400 2010: >> >> >>> However, I think -C is a special case because it's quite un-obvious >>> to the user that it effectively acts as a filter switch --- in fact a >>> de-filtering switch, because the lack of -C is what filters out the >>> DATABASE item. >>> >>> I'm inclined to think that we should document that the output of -l >>> is restricted by -n and similar switches, but change the code so that >>> -C doesn't affect -l output. Comments? >>> >> +1 >> > Was this discussed change made? Was it backported, or only applied to head? I believe this is the commit: http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=3a524653d18f29676b91f740634a673b72beb6b5 It looks like the code was changed, but I don't see any doc updates. -- 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
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. 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. 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. Well it is probably not possible in the general sense anyway especially not if one considers dynamic SQL and stuff in plpgsql and friends - it still feels like a lot of wasted effort(or rather a promise we are tzrying to make but wont be able to hold) for only limited gain to me. 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. well that's why we recommend to use the new version of pg_dump to dump the old cluster if the intention is an upgrade not sure that is any more pain than manually hacking the dump... Stefan -- 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] pg_restore ignores -C when using a restore list -L
Robert Haas writes: > I believe this is the commit: > http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=3a524653d18f29676b91f740634a673b72beb6b5 > It looks like the code was changed, but I don't see any doc updates. Eh? http://archives.postgresql.org/pgsql-committers/2010-05/msg00191.php and following entries 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 #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
On Thu, Jun 10, 2010 at 15:35, Stefan Kaltenbrunner wrote: > 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. > > 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. 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 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. > > well that's why we recommend to use the new version of pg_dump to dump the > old cluster if the intention is an upgrade not sure that is any more pain > than manually hacking the dump... yeah. There are (supposedly?) a lot of *other* cases where using an old version of pg_dump won't work. At least we reserve the right for it to be. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- 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
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 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. > > well that's why we recommend to use the new version of pg_dump to dump > the old cluster if the intention is an upgrade not sure that is any more > pain than manually hacking the dump... Or rename the identifier in the old cluster and modify the application before doing the upgrade. The only valid reason I have heard for allowing this flag (default off), is that some application stacks quote all identifiers and therefore there would be no need to ever change the name of the identifier. In fact, such stacks might already have many identifers that require quoting, like a table called "select". The problem is that some of our reserved keywords change from release to release, and using the old pg_dump causes problems. It is sufficient to require people using such application stacks to use the new pg_dump? >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. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- 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 Thu, Jun 10, 2010 at 9:35 AM, 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 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. > > well that's why we recommend to use the new version of pg_dump to dump the > old cluster if the intention is an upgrade not sure that is any more pain > than manually hacking the dump... 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 have to get 8.4 running on the old server before I wipe it (presumably compiling by hand, since the old version of the distro doesn't ship it), or else manually frobnicate the dump after I wipe it, or else find another server someplace to install 8.4 on and run the dump there prior to the OS upgrade. This really sucks. It's a huge pain in the tail, especially for people who aren't used to compiling PG from source at the drop of a hat. 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. :-) -- 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
Magnus Hagander wrote: > On Thu, Jun 10, 2010 at 15:35, Stefan Kaltenbrunner > wrote: > > 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. > > > > 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. > > 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 the quoting has to be done in the backend, and it would be hard for pg_dump to munge the dump file before sending it to the backend --- it doesn't have enough knowledge, I am afraid. It could try targeting just new keywords, but I am worried that would cause more problems than it fixes. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- 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] pg_restore ignores -C when using a restore list -L
On Thu, Jun 10, 2010 at 9:39 AM, Tom Lane wrote: > Robert Haas writes: >> I believe this is the commit: > >> http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=3a524653d18f29676b91f740634a673b72beb6b5 > >> It looks like the code was changed, but I don't see any doc updates. > > Eh? > http://archives.postgresql.org/pgsql-committers/2010-05/msg00191.php > and following entries Ah, missed that. -- 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
Robert Haas wrote: On Thu, Jun 10, 2010 at 9:35 AM, 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 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. well that's why we recommend to use the new version of pg_dump to dump the old cluster if the intention is an upgrade not sure that is any more pain than manually hacking the dump... 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 have to get 8.4 running on the old server before I wipe it (presumably compiling by hand, since the old version of the distro doesn't ship it), or else manually frobnicate the dump after I wipe it, or else find another server someplace to install 8.4 on and run the dump there prior to the OS upgrade. This really sucks. It's a huge pain in the tail, especially for people who aren't used to compiling PG from source at the drop of a hat. that's actually a limitation of the distribution packaging. Debian (and ubuntu) have solved that issue already and I believe Devrim is working on fixing that for the rpms as well. 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. :-) ESXi is free, so is xen, kvm, virtualbox and whatnot :) Stefan -- 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
* Magnus Hagander (mag...@hagander.net) wrote: > On Thu, Jun 10, 2010 at 15:35, Stefan Kaltenbrunner > 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. > > 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... Personally, I feel that *both* would be useful, and I'd be unhappy with any implementation which didn't include both. That being said, the users that are likely to run into this problem will, imnsho, be much happier if we tell them "oh, just flip option X in your pg_dump" than "go edit the .sql file with vi and find where the problem cases are and fix them". Obviously, we should caveat our response that this will only fix the pg_dump/restore problem and that their applications may need to be fixed. Thanks, Stephen signature.asc Description: Digital signature
Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
Bruce Momjian 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 *old* server to cooperate. Which means BTW that "use the newer pg_dump" is only an 80% solution. So maybe we do need to think about this. The least invasive answer that I can think of is to invent a "force quoting" GUC that's looked at by all the deparsing functions used by pg_dump. We have pg_dump set that once, on backend versions that support it, and then we don't have to run around touching every single deparsing function's signature (and adding extra code paths in pg_dump to deal with older versions not having such functions). But the earliest this could be of use would be a 9.1->9.2 update ... 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 #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
Stephen Frost wrote: * Magnus Hagander (mag...@hagander.net) wrote: On Thu, Jun 10, 2010 at 15:35, Stefan Kaltenbrunner 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. 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... Personally, I feel that *both* would be useful, and I'd be unhappy with any implementation which didn't include both. That being said, the users that are likely to run into this problem will, imnsho, be much happier if we tell them "oh, just flip option X in your pg_dump" than "go edit the .sql file with vi and find where the problem cases are and fix them". Obviously, we should caveat our response that this will only fix the pg_dump/restore problem and that their applications may need to be fixed. 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). Imho SQL is code so you need to threat it that way... This is actually one of the smaller issues that can happen when using an older dump against a new backend and given that we make no promise that this is supported at all I don't think we should pretend we do for a specific issue and in fact only a specific subset of that particular issue. Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Beta 2 build issue
Not sure where this needed to be posted, so guessing it's supposed to be here? I've attempted to emerge beta 2 in Gentoo x64 with a 2.6.31-xen-r12 kernel, but it outputs the following: # less /var/tmp/portage/dev-db/postgresql-base-9.0_beta2/temp/build.log * CPV: dev-db/postgresql-base-9.0_beta2 * REPO: gentoo * USE: amd64 doc elibc_glibc kerberos kernel_linux ldap multilib nls pam readline ssl threads userland_GNU zlib >>> Unpacking source... >>> Unpacking postgresql-9.0beta2.tar.bz2 to >>> /var/tmp/portage/dev-db/postgresql-base-9.0_beta2/work >>> Source unpacked in /var/tmp/portage/dev-db/postgresql-base-9.0_beta2/work >>> Preparing source in >>> /var/tmp/portage/dev-db/postgresql-base-9.0_beta2/work/postgresql-9.0beta2 >>> ... * Applying postgresql-9.0-common.patch ... [ ok ] * Applying postgresql-9.0-base.2.patch ... [ ok ] * Applying postgresql-base-8.4-9.0-heimdal_strlcpy.patch ... [ ok ] * Running autoconf ... [ ok ] >>> Source prepared. >>> Configuring source in >>> /var/tmp/portage/dev-db/postgresql-base-9.0_beta2/work/postgresql-9.0beta2 >>> ... * econf: updating postgresql-9.0beta2/config/config.guess with /usr/share/gnuconfig/config.guess * econf: updating postgresql-9.0beta2/config/config.sub with /usr/share/gnuconfig/config.sub ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64/postgresql-9.0/lib64 --prefix=/usr/lib64/postgresql-9.0 --datadir=/usr/share/postgresql-9.0 --docdir=/usr/share/doc/postgresql-9.0 --sysconfdir=/etc/postgresql-9.0 --includedir=/usr/include/postgresql-9.0 --mandir=/usr/share/postgresql-9.0/man --enable-depend --without-tcl --without-perl --without-python --with-readline --with-krb5 --with-gssapi --enable-nls --with-pam --enable-integer-datetimes --with-openssl --enable-thread-safety --with-zlib --with-ldap checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking which template to use... linux checking whether to build with 64-bit integer date/time support... yes checking whether NLS is wanted... yes checking for default port number... 5432 checking for block size... 8kB checking for segment size... 1GB checking for WAL block size... 8kB checking for WAL segment size... 16MB checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none needed checking if x86_64-pc-linux-gnu-gcc supports -Wdeclaration-after-statement... yes checking if x86_64-pc-linux-gnu-gcc supports -Wendif-labels... yes checking if x86_64-pc-linux-gnu-gcc supports -fno-strict-aliasing... yes checking if x86_64-pc-linux-gnu-gcc supports -fwrapv... yes checking whether the C compiler still works... yes checking how to run the C preprocessor... x86_64-pc-linux-gnu-gcc -E checking allow thread-safe client libraries... yes checking whether to build with Tcl... no checking whether to build Perl modules... no checking whether to build Python modules... no checking whether to build with GSSAPI support... yes checking whether to build with Kerberos 5 support... yes checking whether to build with PAM support... yes checking whether to build with LDAP support... yes ...skipping... fno-strict-aliasing -fwrapv configure: using CPPFLAGS= -D_GNU_SOURCE configure: using LDFLAGS=-Wl,-O1 -Wl,--as-needed configure: creating ./config.status config.status: creating GNUmakefile config.status: creating src/Makefile.global config.status: creating src/include/pg_config.h config.status: creating src/interfaces/ecpg/include/ecpg_config.h config.status: linking src/backend/port/tas/dummy.s to src/backend/port/tas.s config.status: linking src/backend/port/dynloader/linux.c to src/backend/port/dynloader.c config.status: linking src/backend/port/sysv_sema.c to src/backend/port/pg_sema.c config.status: linking src/backend/port/sysv_shmem.c to src/backend/port/pg_shmem.c config.status: linking src/backend/port/dynloader/linux.h to src/include/dynloader.h config.status: linking src/include/port/linux.h to src/include/pg_config_os.h config.status: linking src/makefiles/Makefile.linux to src/Makefile.port >>> Source configured. >>> Compiling source in >>> /var/tmp/portage/dev-db/postgresql-base-9.0_beta2/work/postgresql-9.0beta2 >>> ... make -j5 make -C src all make[1]: Entering directory `/var/tmp/portage/dev-db/postgresql-base-9.0_beta2/work/postgresql-9.0beta2/src' make -C port all make[2]: Entering directory `/var/tmp/portage/dev-db/postgresql-base-9.0_beta2/work/postgresql-9.0beta2/sr
Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
Stefan Kaltenbrunner 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). Yeah, that's a mighty good point. We are certainly not going to try to fix the contents of function bodies. The only things we could possibly fix that we don't handle today (when using the newer pg_dump) are references in views, check constraint expressions, etc. 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] Beta 2 build issue
Thom Brown writes:
> In file included from ../../src/include/c.h:851,
> from crypt.c:44:
> ../../src/include/port.h:392: error: expected identifier or '(' before
> '__extension__'
> ../../src/include/port.h:408: error: conflicting types for 'unsetenv'
> /usr/include/stdlib.h:588: note: previous declaration of 'unsetenv' was here
You need to look into why configure failed to detect that your platform
has unsetenv.
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 #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
* 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 against adding this- code complexity and/or duplication, etc. That being said, I'm less than convinced that it's really all that big of an issue when we're talking about a "quote-everything" flag. That doesn't require figuring out what the reserved words are or anything along those lines that quote_ident() currently deals with. It's plain-jane "search for characters that need to be quoted and handle them appropriately". Sure, if we can find a way to stick that actual source code somewhere that all the pieces which need it can get to it w/o code duplication, that'd be great, but it just doesn't feel like a hard problem to solve or one that requires a huge amount of code.. Thanks, Stephen signature.asc Description: Digital signature
Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
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 the quoting has to be done in the > backend, and it would be hard for pg_dump to munge the dump file before > sending it to the backend --- it doesn't have enough knowledge, I am > afraid. It could try targeting just new keywords, but I am worried that > would cause more problems than it fixes. 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. We don't change what has to be *quoted* inside a quoted identifier terribly often... Thanks, Stephen signature.asc Description: Digital signature
Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stefan Kaltenbrunner 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). > > Yeah, that's a mighty good point. We are certainly not going to try to > fix the contents of function bodies. The only things we could possibly > fix that we don't handle today (when using the newer pg_dump) are > references in views, check constraint expressions, etc. Erm, I don't know that we deal with function-body problems today, even when using the newer version of pg_dump, do we? Don't we set check_function_bodies off, meaning they won't hit the problem till they try to run the function? We use $ quoting for the function bodies entirely otherwise... Thanks, Stephen signature.asc Description: Digital signature
Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
Stephen Frost 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 pg_dump so that it can split apart view and expression definitions to tell what is an identifier and what isn't? BTW, it wouldn't be just one parser, but a different one for each back version supported by pg_dump, else you'll fail on exactly the cases that are of concern here. 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 #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
Stephen Frost 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 Stefan's point is that we could get from maybe an 80% fix to maybe a 90% fix, after expending quite a bit of trouble. Not clear it's worth it. 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 #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost 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 Stefan's point is that we could get from maybe an 80% fix to maybe > a 90% fix, after expending quite a bit of trouble. Not clear it's > worth it. 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 "% of our user base, particularly those more junior, that would benefit". I feel that number to be >10%, and growing. Additionally, those that this would really help are the same people who don't have complex views and/or stored procedures. I'm not a huge fan of using that to argue out of dealing with view definitions (that's certainly a complex problem and I understand the issue you raise there), but I'm not seeing a path to fixing that yet. Thanks for pointing that out. Perhaps that's what we get for having those silly complex VIEW thingies that certain others only added very recently. :) Thanks again, Stephen signature.asc Description: Digital signature
Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
Stephen Frost 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 "% of our user base, particularly > those more junior, that would benefit". I feel that number to be >10%, > and growing. Additionally, those that this would really help are the > same people who don't have complex views and/or stored procedures. Um, I rather doubt that experience level has much of anything to do with one's probability of getting blindsided by new SQL syntax. regards, tom lane PS: unless your definition of "experienced" is "sits on the SQL standards committee" ;-) -- 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
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 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.) > > > > I think it is quite a stretch to consider this a feature. > > How about "a desireable behavior considering the alternatives"? I'm with Robert Haas. -- Á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
Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
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. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- 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
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. 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 #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
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. Stefan -- 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] Beta 2 build issue
On 10 June 2010 15:34, Tom Lane wrote:
> Thom Brown writes:
>> In file included from ../../src/include/c.h:851,
>> from crypt.c:44:
>> ../../src/include/port.h:392: error: expected identifier or '(' before
>> '__extension__'
>> ../../src/include/port.h:408: error: conflicting types for 'unsetenv'
>> /usr/include/stdlib.h:588: note: previous declaration of 'unsetenv' was here
>
> You need to look into why configure failed to detect that your platform
> has unsetenv.
>
Is that heimdal_strlcpy patch normal too?
Thom
--
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] Beta 2 build issue
Thom Brown writes: > On 10 June 2010 15:34, Tom Lane wrote: >> You need to look into why configure failed to detect that your platform >> has unsetenv. > Is that heimdal_strlcpy patch normal too? Sorry, no idea what you're talking about. (I don't do Gentoo.) 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 #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Heikki Linnakangas 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 are a pretty serious > disadvantage. We really should do something about that. Big +1 on that.. I *still* do it by hand much of the time these days (manually hacking out the CREATE TABLE step from the ALTER TABLE; CREATE INDEX piece). We took some steps towards improving that using custom dump formats, iirc, but the patch Simon (iirc) for adding options to pg_dump to have it split things out for the SQL-style dump never did get in (think there were dependency issues and whatnot, and I have to admit that it didn't really have the best UI/parameters). 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) ? Just my 2c. Thanks, Stephen signature.asc Description: Digital signature
Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
* 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 currently doing anyway but just exposed as flags. There was a big/long thread on this on -hackers a while back.. Perhaps we need to go back and figure out what happened. Have to admit, that's one of the reason I like creating wiki pages for these kinds of, even admittedly small, things. Easier to find than searching the archive, ime. Of course, that'll probably change as more things get added to the wiki. :) Thanks, Stephen signature.asc Description: Digital signature
Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
Stephen Frost 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 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 "--data-file=filename", with the schema output still going where it goes now (ie, -f or stdout). 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 #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
* 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 > "--data-file=filename", with the schema output still going where it > goes now (ie, -f or stdout). +1 from me, excellent solution. Thanks, Stephen signature.asc Description: Digital signature
Re: [BUGS] Beta 2 build issue
On 10 June 2010 16:48, Tom Lane wrote: > Thom Brown writes: >> On 10 June 2010 15:34, Tom Lane wrote: >>> You need to look into why configure failed to detect that your platform >>> has unsetenv. > >> Is that heimdal_strlcpy patch normal too? > > Sorry, no idea what you're talking about. (I don't do Gentoo.) > It's a patch applied during the ebuild process. I'm not sure what its role is. In any case, I'll assume that since no-one else has mentioned this issue, there's something wrong with the particular ebuild I'm using. I've raised a bug with Gentoo. Thanks anyway. Thom -- 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 Thu, Jun 10, 2010 at 10:25 AM, Tom Lane wrote: > Bruce Momjian 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 *old* server to cooperate. > > Which means BTW that "use the newer pg_dump" is only an 80% solution. > So maybe we do need to think about this. > > The least invasive answer that I can think of is to invent a "force > quoting" GUC that's looked at by all the deparsing functions used by > pg_dump. We have pg_dump set that once, on backend versions that > support it, and then we don't have to run around touching every single > deparsing function's signature (and adding extra code paths in pg_dump > to deal with older versions not having such functions). > > But the earliest this could be of use would be a 9.1->9.2 update ... That's OK. I don't have an immediate problem I need to solve; I just want to improve things for future users. The fact is, I've had this problem in the past, and it wasn't fun, so, I understand the OP's pain. But there's definitely a workaround until we get this done, it just isn't a particularly enjoyable one. The deparse_force_quoting GUC is a good idea - I bet the number of places that would need to examine the value of that GUC is extremely small. One possible objection is that such a GUC would also affect the output of tools like EXPLAIN, but I'm not sure we really need to worry about that. If someone really wants to force quoting in their EXPLAIN output, I say let 'em. If we really wanted to get sneaky we could even let the value of the GUC be a list of words to force-quote, with * meaning all. That would let a newer server talking to an older server hand over a specific list of keywords that it knows are problem cases, even if the user isn't using --quote-like-crazy. Not sure if we want to go there, though. The idea mentioned on another part of this thread of providing a way to separate schema and data dumps without tanking performance is a good one, too, but I still think this has merit even if we do that. Just because we make it easier to manually edit dump files is not a reason not to create options that render it unnecessary in the first place. -- 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] Beta 2 build issue
Excerpts from Thom Brown's message of jue jun 10 12:20:57 -0400 2010: > On 10 June 2010 16:48, Tom Lane wrote: > > Thom Brown writes: > >> On 10 June 2010 15:34, Tom Lane wrote: > >>> You need to look into why configure failed to detect that your platform > >>> has unsetenv. > > > >> Is that heimdal_strlcpy patch normal too? > > > > Sorry, no idea what you're talking about. (I don't do Gentoo.) > > > > It's a patch applied during the ebuild process. I'm not sure what its > role is. I looked at it and I think it's probably harmless and not related to the unsetenv issue. The interesting lines are: 28 -LIBS=`echo "$LIBS" | sed -e 's/-ledit//g' -e 's/-lreadline//g'` 29 +LIBS=`echo "$LIBS" | sed -e 's/-ledit//g' -e 's/-lreadline//g' -e 's/-lgssapi//g' -e 's/-lkrb5//g'` http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-db/postgresql-base/files/postgresql-base-8.4-9.0-heimdal_strlcpy.patch?view=markup -- Á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
Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
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 quoted. Since I've be confused a bit by your statement, I'll try to express it differently: These frameworks simply qoute *all* identifiers, no matter if the identifier is a keyword or not. This is done to take the burden of the programmer to take care about identifiers. So it simply does not matter when a keyword is added. I wished, pg_dump could do the same and easy admins life :-\ -- Schönen Gruß - Regards Hartmut Goebel Dipl.-Informatiker (univ.), CISSP, CSSLP Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de Monatliche Kolumne: http://www.cissp-gefluester.de/ Goebel Consult mit Mitglied bei http://www.7-it.de smime.p7s Description: S/MIME Cryptographic Signature
Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
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, 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.) >> >> 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! Since this would at least solve one issue: migrating the data. And if the application is developed elsewhere, it should be fixed when I'm upgrading. -- Schönen Gruß - Regards Hartmut Goebel Dipl.-Informatiker (univ.), CISSP, CSSLP Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de Monatliche Kolumne: http://www.cissp-gefluester.de/ Goebel Consult mit Mitglied bei http://www.7-it.de smime.p7s Description: S/MIME Cryptographic Signature
Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
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 have to get 8.4 running > on the old server before I wipe it (presumably compiling by hand, > since the old version of the distro doesn't ship it), or else manually > frobnicate the dump after I wipe it, or else find another server > someplace to install 8.4 on and run the dump there prior to the OS > upgrade. This really sucks. It's a huge pain in the tail, especially > for people who aren't used to compiling PG from source at the drop of > a hat. +1 > 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. +1 -- Schönen Gruß - Regards Hartmut Goebel Dipl.-Informatiker (univ.), CISSP, CSSLP Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de Monatliche Kolumne: http://www.cissp-gefluester.de/ Goebel Consult mit Mitglied bei http://www.7-it.de smime.p7s Description: S/MIME Cryptographic Signature
Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
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 the update. He is a junior admin. He doe not want (nor has time and budget) taking a course, just to upgrade da database. Hej, let's educate the juniors! They should fall into all the pitfalls, we've fallen in. We aren't they reading all of our fine postgresql manual, subscribe to five mailing lists, become a senior and then upgrade? *Gnaa* Com'on guy! Is it really that hard to understand that others are no gurus and have to upgrade anyway?! Why are you fighting to make their life harder? -- Schönen Gruß - Regards Hartmut Goebel Dipl.-Informatiker (univ.), CISSP, CSSLP Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de Monatliche Kolumne: http://www.cissp-gefluester.de/ Goebel Consult mit Mitglied bei http://www.7-it.de smime.p7s Description: S/MIME Cryptographic Signature
Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
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 Dipl.-Informatiker (univ.), CISSP, CSSLP Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de Monatliche Kolumne: http://www.cissp-gefluester.de/ Goebel Consult mit Mitglied bei http://www.7-it.de smime.p7s Description: S/MIME Cryptographic Signature
Re: [BUGS] Beta 2 build issue
On 10 June 2010 17:48, Alvaro Herrera wrote: > Excerpts from Thom Brown's message of jue jun 10 12:20:57 -0400 2010: >> On 10 June 2010 16:48, Tom Lane wrote: >> > Thom Brown writes: >> >> On 10 June 2010 15:34, Tom Lane wrote: >> >>> You need to look into why configure failed to detect that your platform >> >>> has unsetenv. >> > >> >> Is that heimdal_strlcpy patch normal too? >> > >> > Sorry, no idea what you're talking about. (I don't do Gentoo.) >> > >> >> It's a patch applied during the ebuild process. I'm not sure what its >> role is. > > I looked at it and I think it's probably harmless and not related to the > unsetenv issue. The interesting lines are: > > 28 -LIBS=`echo "$LIBS" | sed -e 's/-ledit//g' -e 's/-lreadline//g'` > 29 +LIBS=`echo "$LIBS" | sed -e 's/-ledit//g' -e 's/-lreadline//g' -e > 's/-lgssapi//g' -e 's/-lkrb5//g'` > > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-db/postgresql-base/files/postgresql-base-8.4-9.0-heimdal_strlcpy.patch?view=markup > Here's a mindless stab at a solution... should I disable kerberos in the build? Thom -- 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] Beta 2 build issue
Excerpts from Thom Brown's message of jue jun 10 13:11:25 -0400 2010: > Here's a mindless stab at a solution... should I disable kerberos in the > build? I suggest you look at config.log to try to determine what's the problem with unsetenv. -- Á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 #5498: PgAdmin III write to file adds carriage return
The following bug has been logged online: Bug reference: 5498 Logged by: Ramesh Email address: ramn...@rediffmail.com PostgreSQL version: 8.1.7 Operating system: Linux Description:PgAdmin III write to file adds carriage return Details: I have connected PgAdmin III version 1.10.3 to PostgresSQL database version 8.1.7. I am trying to generate a report with comma (,) seperated values and the columns are with in double quotes. Once its saved when I check the report the last column is like below, after the value is printed a carriage return is added (\n) to the last column and then a quote is added. "a","b","c","d " "e","f","g","h " Can some point me a fix for this ? -- 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] Invalid YAML output from EXPLAIN
Robert Haas wrote:
> On Wed, Jun 9, 2010 at 4:48 PM, Robert Haas wrote:
> > On Wed, Jun 9, 2010 at 4:47 PM, Dean Rasheed
> > wrote:
> >> On 9 June 2010 20:56, Robert Haas wrote:
> >>> On Wed, Jun 9, 2010 at 3:50 PM, Tom Lane wrote:
> Dean Rasheed writes:
> > Hmm. Well it's quite subjective, but IMO it's already more readable
> > than JSON regardless of whether or not values are quoted, simply
> > because it doesn't have [ ] and { } for lists and maps, which for JSON
> > adds significantly to the number of lines in longer plans.
>
> Yeah. ?Also, I think it would be fair to not quote values that are known
> constants (for example, Node Type: Seq Scan) and are chosen to not need
> quoting. ?It's just the things that are variables that worry me.
> >>>
> >>> Passing down information about which things are known constants seems
> >>> more complicated to me than just getting the quoting rules right in
> >>> the first place. ?If you look at the patch I proposed, you'll see that
> >>> it's really quite simple and only a slight tightening of what I
> >>> committed already.
> >>>
> >>
> >> Reading the YAML spec, I've just spotted yet another case that'll
> >> break what you're proposing: if you don't quote "true" and "false",
> >> the parser will think they're booleans rather than strings.
> >>
> >> This is really why I'm opposed to this approach. There are just so
> >> many gotchas that it's impossible to be 100% sure that you've
> >> accounted for them all.
> >
> > OK, I give up.
>
> I have committed your patch, with some changes to the comments.
>
> Thanks for bearing with me.
So, is there still value to a YAML format vs. JSON? They look similar
to me in this simple case:
test=> EXPLAIN (FORMAT JSON) SELECT * FROM pg_class;
QUERY PLAN
[ +
{ +
"Plan": { +
"Node Type": "Seq Scan",+
"Relation Name": "pg_class",+
"Alias": "pg_class",+
"Startup Cost": 0.00, +
"Total Cost": 9.53, +
"Plan Rows": 253, +
"Plan Width": 190 +
} +
} +
]
(1 row)
test=> EXPLAIN (FORMAT YAML) SELECT * FROM pg_class;
QUERY PLAN
---
- Plan: +
Node Type: "Seq Scan"+
Relation Name: "pg_class"+
Alias: "pg_class"+
Startup Cost: 0.00 +
Total Cost: 9.53 +
Plan Rows: 253 +
Plan Width: 190
(1 row)
Is unquoted identifiers the only value for YAML?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ None of us is going to be here forever. +
--
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] Invalid YAML output from EXPLAIN
Bruce Momjian writes: > So, is there still value to a YAML format vs. JSON? They look similar > to me in this simple case: Well, removing the various braces and brackets reduces the line count significantly. Not convinced it's really worth much though. 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] Invalid YAML output from EXPLAIN
Tom Lane wrote: > Bruce Momjian writes: > > So, is there still value to a YAML format vs. JSON? They look similar > > to me in this simple case: > > Well, removing the various braces and brackets reduces the line count > significantly. Not convinced it's really worth much though. Ah, I see that now. Thanks. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- 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 #5497: plpythonu gives cache lookup error
Thanks, was able to rebuild plpython.so and it works. Also mapping SQL Arrays to Python lists is awesome. On 06/09/2010 09:05 PM, Tom Lane wrote: "David Gardner" writes: Description:plpythonu gives cache lookup error Fixed, thanks for the report! regards, tom lane -- David Gardner Pipeline Tools Programmer Jim Henson Creature Shop dgard...@creatureshop.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
