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 l
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
> a
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:
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 o
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 fo
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
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: M
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 us
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
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 o
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
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 a
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
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 some
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
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?
> ht
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 le
* 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 d
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
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
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_beta
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 might
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:
* 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 argumen
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 muc
* 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
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 ca
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 tha
* 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 wi
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
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 t
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, fo
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 leavin
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
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 typ
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, t
* 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
> disadvant
* 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 curr
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 complicatio
* 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 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
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.
>
>
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 hei
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 qu
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.
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
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 t
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
Dip
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 yo
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 P
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 v
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 subj
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
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 tha
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!
reg
55 matches
Mail list logo
