Joel Jacobson wrote:
> On Wed, Oct 17, 2012 at 11:43 PM, Alvaro Herrera
> 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 unfortu
On Wed, Oct 17, 2012 at 11:43 PM, Alvaro Herrera
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 cannot use the value comp
On Wed, Oct 17, 2012 at 5:43 PM, Alvaro Herrera
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 pg_get_function_iden
Joel Jacobson wrote:
> On Thu, Jul 5, 2012 at 10:33 PM, Tom Lane 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 =
>
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 avo
On Thu, Jul 5, 2012 at 10:33 PM, Tom Lane 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 =
format_function_arguments(finfo, func
Roger that. I'm on it.
On Thursday, July 5, 2012, Tom Lane wrote:
> Joel Jacobson > 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 lane
>
Joel Jacobson 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 DumpableObject.
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 > writes:
> > New version, made a typo in last one.
>
> I'm not particularly happy with the idea of adding a so
Joel Jacobson 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
modify the already-
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
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/aggregate
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
Thi
13 matches
Mail list logo