On Wed, Oct 17, 2012 at 11:43 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Uh, the patch you posted keeps the pg_get_function_identity_arguments
call in dumpFunc, but there is now also a new one in getFuncs. Do we
need to remove the second one?
It could be done, but unfortunately we
Joel Jacobson wrote:
On Wed, Oct 17, 2012 at 11:43 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Uh, the patch you posted keeps the pg_get_function_identity_arguments
call in dumpFunc, but there is now also a new one in getFuncs. Do we
need to remove the second one?
It could be
Joel Jacobson wrote:
On Thu, Jul 5, 2012 at 10:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
You may in fact need a new field --- I'm just saying it should be in the
object-type-specific struct, eg FuncInfo, not DumpableObject.
I suggest adding char *funcsig to FuncInfo, and moving the
On Wed, Oct 17, 2012 at 5:43 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
(I tested the new pg_dump with 8.2 and HEAD and also verified it passes
pg_upgrade's make check. I didn't test with other server versions.)
I also tested against 8.3 and 8.4 since 8.4 is the version that
introduced
Makes pg_dump sort overloaded functions in deterministic order.
The field proiargs has been added to FuncInfo and is set by getFuncs()
and getAggregates() for all functions and aggregates.
DOTypeNameCompare uses this field to break ties if the name and number of
arguments are the same. This
On Thu, Jul 5, 2012 at 10:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
You may in fact need a new field --- I'm just saying it should be in the
object-type-specific struct, eg FuncInfo, not DumpableObject.
I suggest adding char *funcsig to FuncInfo, and moving the funcsig =
New version, made a typo in last one.
pg_dump_deterministic_order_v3.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Joel Jacobson j...@trustly.com writes:
New version, made a typo in last one.
I'm not particularly happy with the idea of adding a sortkey field to
DumpableObject as such, when most object types don't need it. That just
bloats the code and pg_dump's memory consumption. It would be better to
I agree, good suggestion, I just didn't know how to implement it without a
new field. I'll make a new attempt to get it right.
On Thursday, July 5, 2012, Tom Lane wrote:
Joel Jacobson j...@trustly.com javascript:; writes:
New version, made a typo in last one.
I'm not particularly happy with
Joel Jacobson j...@trustly.com writes:
I agree, good suggestion, I just didn't know how to implement it without a
new field. I'll make a new attempt to get it right.
You may in fact need a new field --- I'm just saying it should be in the
object-type-specific struct, eg FuncInfo, not
Roger that. I'm on it.
On Thursday, July 5, 2012, Tom Lane wrote:
Joel Jacobson j...@trustly.com javascript:; writes:
You may in fact need a new field --- I'm just saying it should be in the
object-type-specific struct, eg FuncInfo, not DumpableObject.
regards, tom
I have received positive feedback on the pg_dump --split option I suggested,
but it depends on pg_dump dumping objects in a deterministic order.
I'm committed to fixing this. The first problem I've spotted is overloaded
functions.
This patch adds a new element to DumpableObject: char *proargs
I renamed the new element to DumpableObject from proargs to the more
general name sortkey.
This way this element can be used by any object types in the future,
which might require sorting by additional information than type, namespace
and name.
Currently, it's only set for functions/aggregates
13 matches
Mail list logo
