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
Peter Eisentraut pete...@gmx.net 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
On 2014-01-06 11:56:28 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
Andres Freund and...@2ndquadrant.com 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
On 2014-01-07 10:04:33 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
Andres Freund and...@2ndquadrant.com 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.
On 2014-01-07 11:08:22 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
Hi,
Does anybody have an opinion about introducing generic pseudotype IO
functions? Pseudotype.c/pg_proc.h are slowly growing a number of pretty
useless/redundant copypasted functions... Most for cases that are
pretty damn unlikely to be hit by users not knowing what they do.
What about adding a
On 2014-01-06 10:29:06 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
Andres Freund and...@2ndquadrant.com 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 copypasted functions... Most for cases that are
pretty damn unlikely to be hit
On 1/6/14, 10:29 AM, Tom Lane wrote:
Pseudotype.c/pg_proc.h are slowly growing a number of pretty
useless/redundant copypasted 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 inventing a new
Peter Eisentraut pete...@gmx.net 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
On 2014-01-06 11:28:29 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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?
Andres Freund and...@2ndquadrant.com 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
14 matches
Mail list logo
