Peter Eisentraut writes:
> Since we ran out of time/ideas on this, I would propose just committing
> the part that breaks ties based on the number of arguments, which
> already solves a large part of the problem (at least in a pre-default
> values world) and would very likely be a part of any poss
On tis, 2010-01-12 at 16:35 +0200, Peter Eisentraut wrote:
> Um, that tag is the "name", and if you change that, the name in CREATE
> FUNCTION also changes. I was initially thinking in that direction, but
> it seems it won't be feasible without significant refactoring.
>
> In the mean time, hacki
I wrote:
> Peter Eisentraut writes:
>> On mån, 2010-01-11 at 12:54 -0500, Tom Lane wrote:
>>> -- Name: binary_coercible(oid, oid); Type: FUNCTION; Schema: public; Owner:
>>> postgres
>> Um, that tag is the "name", and if you change that, the name in CREATE
>> FUNCTION also changes.
> So?
Actu
On Tue, Jan 12, 2010 at 15:59, Tom Lane wrote:
> Magnus Hagander writes:
>> Sorry if this is talking about something completely different, haven't
>> followed the thread closely, but: will this change the output of
>> pg_restore -l? If so, changing the tag is likely to break scripts, and
>> IMHO
Magnus Hagander writes:
> Sorry if this is talking about something completely different, haven't
> followed the thread closely, but: will this change the output of
> pg_restore -l? If so, changing the tag is likely to break scripts, and
> IMHO should be avoided if possible.
Only to the extent of
On Tue, Jan 12, 2010 at 15:44, Tom Lane wrote:
> Peter Eisentraut writes:
>> On mån, 2010-01-11 at 12:54 -0500, Tom Lane wrote:
>>> -- Name: binary_coercible(oid, oid); Type: FUNCTION; Schema: public; Owner:
>>> postgres
>
>> Um, that tag is the "name", and if you change that, the name in CREATE
Peter Eisentraut writes:
> On mån, 2010-01-11 at 12:54 -0500, Tom Lane wrote:
>> -- Name: binary_coercible(oid, oid); Type: FUNCTION; Schema: public; Owner:
>> postgres
> Um, that tag is the "name", and if you change that, the name in CREATE
> FUNCTION also changes.
So?
> In the mean time, ha
On mån, 2010-01-11 at 12:54 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > On mån, 2010-01-11 at 10:44 -0500, Tom Lane wrote:
> >> I think you could probably use the existing tag field; no need for a new
> >> one.
>
> > Sorry, which tag field are you referring to?
>
> The one called "tag"
Peter Eisentraut writes:
> On mån, 2010-01-11 at 10:44 -0500, Tom Lane wrote:
>> I think you could probably use the existing tag field; no need for a new
>> one.
> Sorry, which tag field are you referring to?
The one called "tag" in the source code. It prints out as "Name":
--
-- Name: binary
On mån, 2010-01-11 at 10:44 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > pg_dump sorts its output first by object type, then by object name, and
> > then processes all that for dependencies. This works well, but for
> > overloaded functions this still gives a random sort order that can
>
Peter Eisentraut writes:
> pg_dump sorts its output first by object type, then by object name, and
> then processes all that for dependencies. This works well, but for
> overloaded functions this still gives a random sort order that can
> produce annoying diffs in the dump.
> Would it be accepta
pg_dump sorts its output first by object type, then by object name, and
then processes all that for dependencies. This works well, but for
overloaded functions this still gives a random sort order that can
produce annoying diffs in the dump.
Would it be acceptable to introduce a secondary sort ke
12 matches
Mail list logo
