Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.databases.postgresql > #301 > unrolled thread

User-defined type send/recv vs. out/in

Back to article view | Back to comp.databases.postgresql

Contents

  User-defined type send/recv vs. out/in Don Y <this@isnotme.com> - 2012-02-12 22:31 -0700
    Re: User-defined type send/recv vs. out/in Jasen Betts <jasen@xnet.co.nz> - 2012-02-13 09:33 +0000
      Re: User-defined type send/recv vs. out/in Don Y <this@isnotme.com> - 2012-02-13 14:06 -0700
        Re: User-defined type send/recv vs. out/in Jasen Betts <jasen@xnet.co.nz> - 2012-02-14 11:15 +0000
          Re: User-defined type send/recv vs. out/in Don Y <this@isnotme.com> - 2012-02-14 22:57 -0700

#301 — User-defined type send/recv vs. out/in

Hi,

While in() and out() routines are required for a type,
recv() and send() are "optional".

Could someone clarify when recv/send are used in preference
to in/out?  Any way to force the use of one set or the
other (assuming all are defined)?

And, while I'm at it, any pointers to a comprehensive
summary of these issues?  (I've been poking through
the source distribution...)

Thx,
--don

[toc] | [next] | [standalone]

#303

On 2012-02-13, Don Y <this@isnotme.com> wrote:
> Hi,
>
> While in() and out() routines are required for a type,
> recv() and send() are "optional".

I can't find that twxt anywhere.

> Could someone clarify when recv/send are used in preference
> to in/out?  Any way to force the use of one set or the
> other (assuming all are defined)?

I'm guessing in/out is for disk storage and send/recv
for the line protocol.

> And, while I'm at it, any pointers to a comprehensive
> summary of these issues?  (I've been poking through
> the source distribution...)

I didn't look at that, that's probably whay I didn't find it.

there's a mailing list "postgresql.hackers" where the people who
work on the deep internals hang out. you can reach it thuough 
gmane if you prefer an NNTP interface, but you need to sign up at
http://www.postgresql.org/community/lists/ to post.

-- 
⚂⚃ 100% natural

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#304

Hi Jasen,

On 2/13/2012 2:33 AM, Jasen Betts wrote:
> On 2012-02-13, Don Y<this@isnotme.com>  wrote:

>> While in() and out() routines are required for a type,
>> recv() and send() are "optional".
>
> I can't find that twxt anywhere.

Part of the standard manual:

<http://www.postgresql.org/docs/7.4/static/xtypes.html>

(Sorry I posted the URL for v7.4... the text is largely
the same for subsequent versions).

Note, specifically, the casual mention of the send and recv
functions...

>> Could someone clarify when recv/send are used in preference
>> to in/out?  Any way to force the use of one set or the
>> other (assuming all are defined)?
>
> I'm guessing in/out is for disk storage and send/recv
> for the line protocol.

in and out talk "people-speak".  I.e., they provide a way
to convey the contents of the typed variable to the human
user.  I.e., it imposes the syntax that the type wants
(as defined by the type implementor) and provides a mapping
to/from the internal representation.

send and recv are for "binary I/O".  The first thing that comes
to mind is a *dump*.  But, dumps generate actual SQL so...
(obviously, there is a way that send/recv can be used.  The
question is:  what drives/invokes that and what are the
consequences if it is not implemented?)

>> And, while I'm at it, any pointers to a comprehensive
>> summary of these issues?  (I've been poking through
>> the source distribution...)
>
> I didn't look at that, that's probably whay I didn't find it.

There's a tutorial there (that mimics the one on the manual page)

> there's a mailing list "postgresql.hackers" where the people who
> work on the deep internals hang out. you can reach it thuough
> gmane if you prefer an NNTP interface, but you need to sign up at
> http://www.postgresql.org/community/lists/ to post.

Yes, I've been trying to avoid pestering those folks on the
assumption that they have better things to do than attend to my
"simple" questions  :-/  I figured the user types are exposed
in the manual (whereas much of the internals are NOT) so hoping
other "users" would have first-hand experience.

[toc] | [prev] | [next] | [standalone]

#305

On 2012-02-13, Don Y <this@isnotme.com> wrote:

> send and recv are for "binary I/O".  The first thing that comes
> to mind is a *dump*.  But, dumps generate actual SQL so...
> (obviously, there is a way that send/recv can be used.  The
> question is:  what drives/invokes that and what are the
> consequences if it is not implemented?)

obvously the text form is need for server features like COPY ... TO
and COPY ... FROM , (and the binary form when using the WITH BINARY
clause on COPY) but this is not the whole picture...

this page discusses binary format when using libpq
http://www.postgresql.org/docs/9.1/static/libpq-exec.html

It seems if you use a special query function like PQexecparams 
you can ask for the results in binary else if you use
ordinary PQexec you're only going to get them in text.

if you're not using libpq (eg using java or odbc) yuo'll probably only
be able to use the text form.

>> there's a mailing list "postgresql.hackers" where the people who
>> work on the deep internals hang out. you can reach it thuough
>> gmane if you prefer an NNTP interface, but you need to sign up at
>> http://www.postgresql.org/community/lists/ to post.
>
> Yes, I've been trying to avoid pestering those folks on the
> assumption that they have better things to do than attend to my
> "simple" questions  :-/  I figured the user types are exposed
> in the manual (whereas much of the internals are NOT) so hoping
> other "users" would have first-hand experience.

The developers (especially Tom Lane) seem to be happy to help out
people with tricky questions in the general mailing list. 
that's a high volume list (~100/day).  people with easy questions are
usually helped by the other list members.

-- 
⚂⚃ 100% natural

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#308

Hi Jasen,

On 2/14/2012 4:15 AM, Jasen Betts wrote:
> On 2012-02-13, Don Y<this@isnotme.com>  wrote:
>
>> send and recv are for "binary I/O".  The first thing that comes
>> to mind is a *dump*.  But, dumps generate actual SQL so...
>> (obviously, there is a way that send/recv can be used.  The
>> question is:  what drives/invokes that and what are the
>> consequences if it is not implemented?)
>
> obvously the text form is need for server features like COPY ... TO
> and COPY ... FROM , (and the binary form when using the WITH BINARY
> clause on COPY) but this is not the whole picture...
>
> this page discusses binary format when using libpq
> http://www.postgresql.org/docs/9.1/static/libpq-exec.html
>
> It seems if you use a special query function like PQexecparams
> you can ask for the results in binary else if you use
> ordinary PQexec you're only going to get them in text.

Yes.  Notably absent (implied?) are the consequences of specifying
a "binary" pgFormats[] indicator for a paramType[] that doesn't
have _send/_recv() support.  (I suppose the interface could
silently replace a "text" format on each end of the API and
just incur the performance hit.  Of course, it could also
*complain*!  :> )

> if you're not using libpq (eg using java or odbc) yuo'll probably only
> be able to use the text form.
>
>>> there's a mailing list "postgresql.hackers" where the people who
>>> work on the deep internals hang out. you can reach it thuough
>>> gmane if you prefer an NNTP interface, but you need to sign up at
>>> http://www.postgresql.org/community/lists/ to post.
>>
>> Yes, I've been trying to avoid pestering those folks on the
>> assumption that they have better things to do than attend to my
>> "simple" questions  :-/  I figured the user types are exposed
>> in the manual (whereas much of the internals are NOT) so hoping
>> other "users" would have first-hand experience.
>
> The developers (especially Tom Lane) seem to be happy to help out
> people with tricky questions in the general mailing list.
> that's a high volume list (~100/day).  people with easy questions are
> usually helped by the other list members.

I think I've found a work-around that truly makes send/recv
"optional" in my case.  My original query was motivated by
fear over what *might* want to rely on that instead of in/out
but I think I've eliminated that concern (coupled with your
pointers, above)

Thanks!
--don

[toc] | [prev] | [standalone]

Back to top | Article view | comp.databases.postgresql

csiph-web