Обсуждение: 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