Обсуждение: input/output functions have been changed ?
HI all, I just want to confirm if input/output functions have been changed. In my environment(current cvs),I get the following. Unfortunately it isn't the latest one because I wasn't able to update my cvs tree yesterday select int4out(1); int4out ----------- 136475032 (1 row) Regards. Hiroshi Inoue Inoue@tpf.co.jp
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes: > I just want to confirm if input/output functions have > been changed. > select int4out(1); > int4out > ----------- > 136475032 > (1 row) Sure, you expected something nicer? You're seeing the numeric representation of a C string pointer. Actually, checking 6.5, I see that int4out --- alone of all the *out functions --- used to be declared in pg_proc to return type 'name'. All the other ones are declared to return type 'int4', which means if you invoke them explicitly as in the above example, you'll see the numeric equivalent of whatever pointer value they return. 'name' is not a correct declaration either since it implies a string of < NAMEDATALEN chars, but it would have happened to produce the right sort of results. I changed int4out to be the same as the other *out functions recently, just for consistency's sake. Really the right fix is to assign a real type OID to represent "C string" so that the argument and return types of input/output functions can be declared honestly. We've talked about that before, and I've been thinking about making a concrete proposal for it, but haven't done anything yet... regards, tom lane
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > > "Hiroshi Inoue" <Inoue@tpf.co.jp> writes: > > I just want to confirm if input/output functions have > > been changed. > > > select int4out(1); > > int4out > > ----------- > > 136475032 > > (1 row) > > Sure, you expected something nicer? You're seeing the numeric > representation of a C string pointer. > > Actually, checking 6.5, I see that int4out --- alone of all the *out > functions --- used to be declared in pg_proc to return type 'name'. Oops,int4out() alone. I don't complain about this change. It seems not good for clients to call input/output functions directly. There remains a pair of int4out() calls in interfaces/odbc/info.c. I don't know why those calls have been needed but this change would return wrong result. Probably we should remove the calls from info.c completely. Regards. Hiroshi Inoue Inoue@tpf.co.jp
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes: > It seems not good for clients to call input/output functions directly. I agree, but if we don't prevent it maybe we should make it work reasonably ... > There remains a pair of int4out() calls in interfaces/odbc/info.c. > I don't know why those calls have been needed but this change > would return wrong result. Oh, I missed those --- didn't notice references outside the backend. Hmm: strcat(tables_query, " and relname !~ '^xinv[0-9]+'"); strcat(tables_query, " and int4out(usesysid) = int4out(relowner)"); strcat(tables_query, "order by relname"); That seems absolutely wacko ... why not just "usesysid = relowner"? Now that I look, there are several other pretty silly-looking invocations of int4out in src/interfaces/python/tutorial/syscat.py src/test/regress/sql/view_perms.sql src/tutorial/syscat.source The one in view_perms.sql is not only especially bizarre, but it's still passing regress test! Wow... regards, tom lane