Re: PG_RETURN_?

Martijn van Oosterhout wrote:
> On Tue, May 02, 2006 at 10:06:19AM -0700, Don Y wrote:
>>> The type as declared determines the storage required to store it. That
>> Yes, but for a function returning a value that does not exceed
>> sizeof(Datum), there is no *space* consequence.  I would assume
>> most modern architectures use 32 bit (and larger) registers.
>
> When you return a Datum, it's always the same size. When you're
> returning a string, you're still returning a Datum, which may be 4 or 8
> bytes depending on the platform.

Yes.

> But what I was referring to was the space to store the data in a tuple
> on disk, or to send the data to a client. These are affected by the
> choice of representation.

So, as I had mentioned before, you marshall as a *byte* stream
and not a *Datum* stream?

>> OTOH, some machines incur a (tiny) penalty for casting char to long.
>> Returning INT32 *may* be better from that standpoint -- assuming
>> there is no added offsetting cost marshalling.
>
> Within the backend the only representations used are Datum and tuples.
> I don't think either of them would have a noticable difference between
> various pass-by-value formats.
>
>> ... I'd be annoyed to have
>> built dozens of functions ASSUMING "INT32" when a *better*
>> assumption might have been "CHAR"...  (I'm working in an
>> embedded environment where "spare CPU cycles" mean you've
>> wasted $$$ on hardware that you don't need  :-/ )
>
> Hmm, postgres doesn't try to save on cycles.

<grin> Yes, I noticed.  :>  But it's hard for me to get this
"attitude" out of the way I approach a problem.  :-(
(e.g., I wouldn't count people at a rally using a *float*!  :>)

 > the philosophy is to get
> it right first, then make it fast. The entire fmgr interface is slower
> than the original design (old-style functions), but this design works
> on all platforms whereas the old one didn't.

Exactly.  I could more "efficiently" replace postgres with
dedicated structures to do what I want.  But, that ties my
implementation down to one less portable (and maintainable).

> I'd go for INT32, it's most likely to be an "int" which should be "the
> most natural size for the machine".

(sigh)  Yes, I suppose so.  Though it can have a big impact
on transport delays (server to client) if things really
are marshalled as byte streams, etc.

<shrug>  I suppose I should just "do it" and let technology
catch up with my inefficiencies later!

Thanks!
--don