Peter Eisentraut writes:
> On Mon, 2014-01-06 at 17:36 +0100, Andres Freund wrote:
>> FWIW, I am perfectly fine with duplicating the functions for now - I
>> just thought that that might not be the best way but I didn't (and
>> still don't) have a strong opinion.
> Could we just put 0 in for the
On Mon, 2014-01-06 at 17:36 +0100, Andres Freund wrote:
> FWIW, I am perfectly fine with duplicating the functions for now - I
> just thought that that might not be the best way but I didn't (and
> still
> don't) have a strong opinion.
Could we just put 0 in for the functions' OID and have code el
On 2014-01-07 11:08:22 -0500, Tom Lane wrote:
> Andres Freund writes:
> > To the point that I am not seing the problem right now. I am not
> > proposing to get rid of statically assigned oids in pg_type et al.. The
> > references to procs mostly seem to be typed 'regproc' so there aren't
> > many
Andres Freund writes:
> To the point that I am not seing the problem right now. I am not
> proposing to get rid of statically assigned oids in pg_type et al.. The
> references to procs mostly seem to be typed 'regproc' so there aren't
> many references to function's oids.
*Some* of them are typed
On 2014-01-07 10:04:33 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I think we also should auto-assign the oids for pg_proc (and some other
> > tables) rows if we go there.
>
> -1 ... you've evidently not built any opclasses lately.
True. Not sure if I ever built one, but when playing arou
Andres Freund writes:
> I think we also should auto-assign the oids for pg_proc (and some other
> tables) rows if we go there.
-1 ... you've evidently not built any opclasses lately.
Yeah, we could probably improve the bootstrap infrastructure enough to not
need literal OIDs in so many places in
On 2014-01-06 11:56:28 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I think I am less concerned about pseudotypes.c than about bloating
> > pg_proc.h even further and about the annoyance of editing it - but I
> > guess that should rather be fixed by storing it in a more sensible
> > format a
Andres Freund writes:
> I think I am less concerned about pseudotypes.c than about bloating
> pg_proc.h even further and about the annoyance of editing it - but I
> guess that should rather be fixed by storing it in a more sensible
> format at some point...
Yeah, getting rid of a dozen pseudotype
On 2014-01-06 11:28:29 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > On 1/6/14, 10:29 AM, Tom Lane wrote:
> >> This will break some of the function sanity checks in opr_sanity,
>
> > Then the tests can be changed.
>
> That will weaken their ability to detect actual mistakes, no?
FWIW, I
Peter Eisentraut writes:
> On 1/6/14, 10:29 AM, Tom Lane wrote:
>> This will break some of the function sanity checks in opr_sanity,
> Then the tests can be changed.
That will weaken their ability to detect actual mistakes, no?
If there were a large benefit to merging the pseudotype I/O functio
On 1/6/14, 10:29 AM, Tom Lane wrote:
>> Pseudotype.c/pg_proc.h are slowly growing a number of pretty
>> useless/redundant copy&pasted functions... Most for cases that are
>> pretty damn unlikely to be hit by users not knowing what they do.
>
> That's hardly the largest cost associated with inventi
On 2014-01-06 10:29:06 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Does anybody have an opinion about introducing generic pseudotype IO
> > functions?
>
> Yes: -1.
Ok, fine with me.
> > Pseudotype.c/pg_proc.h are slowly growing a number of pretty
> > useless/redundant copy&pasted functio
Andres Freund writes:
> Does anybody have an opinion about introducing generic pseudotype IO
> functions?
Yes: -1.
> Pseudotype.c/pg_proc.h are slowly growing a number of pretty
> useless/redundant copy&pasted functions... Most for cases that are
> pretty damn unlikely to be hit by users not kno
13 matches
Mail list logo