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
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
On Thu, Jun 10, 2010 at 3:58 AM, Russell Smith mr-r...@pws.com.au 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
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
Robert Haas robertmh...@gmail.com 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?
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
On Thu, Jun 10, 2010 at 9:39 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
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
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:
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).
Thom Brown thombr...@gmail.com 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'
* 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.
On 10 June 2010 15:34, Tom Lane t...@sss.pgh.pa.us wrote:
Thom Brown thombr...@gmail.com 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__'
Thom Brown thombr...@gmail.com writes:
On 10 June 2010 15:34, Tom Lane t...@sss.pgh.pa.us 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.)
* 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 10 June 2010 16:48, Tom Lane t...@sss.pgh.pa.us wrote:
Thom Brown thombr...@gmail.com writes:
On 10 June 2010 15:34, Tom Lane t...@sss.pgh.pa.us wrote:
You need to look into why configure failed to detect that your platform
has unsetenv.
Is that heimdal_strlcpy patch normal too?
Sorry,
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
Excerpts from Thom Brown's message of jue jun 10 12:20:57 -0400 2010:
On 10 June 2010 16:48, Tom Lane t...@sss.pgh.pa.us wrote:
Thom Brown thombr...@gmail.com writes:
On 10 June 2010 15:34, Tom Lane t...@sss.pgh.pa.us wrote:
You need to look into why configure failed to detect that your
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
On 10 June 2010 17:48, Alvaro Herrera alvhe...@commandprompt.com wrote:
Excerpts from Thom Brown's message of jue jun 10 12:20:57 -0400 2010:
On 10 June 2010 16:48, Tom Lane t...@sss.pgh.pa.us wrote:
Thom Brown thombr...@gmail.com writes:
On 10 June 2010 15:34, Tom Lane t...@sss.pgh.pa.us
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 alvhe...@commandprompt.com
The
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
Robert Haas wrote:
On Wed, Jun 9, 2010 at 4:48 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jun 9, 2010 at 4:47 PM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
On 9 June 2010 20:56, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jun 9, 2010 at 3:50 PM, Tom Lane
Bruce Momjian br...@momjian.us 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.
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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,
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 Gardnerdgard...@creatureshop.com writes:
Description:plpythonu gives cache lookup error
Fixed, thanks for the report!
54 matches
Mail list logo
