Return-Path: postarch
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA21554; Thu, 30 Jan 92 12:42:09 -0800
Message-Id: <9201302042.AA21554@postgres.Berkeley.EDU>
From: postarch (Postgres Mailing Archive)
Subject: Re: libpq philosophy, perl and Postgres...
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
Reply-To: mer@postgres.berkeley.edu
In-Reply-To: Your message of "Wed, 29 Jan 92 19:59:55 PST."
             <9201300359.AA12380@postgres.Berkeley.EDU> 
Date: Thu, 30 Jan 92 12:41:59 PST

you write:

> --- I mistakenly sent this to postarch ---

I can usually pick out the real messages from the mailer-error
one's (but not always).

> Ok, due to the lack of a deafening roar from the masses of people who
> are polishing up the pgperl from the contrib section of the
> postgres3.x release, I went ahead and did it myself.  I have a first
> cut of something that works (it runs testlibpq after adding a
> begin/end), but I need some philosophical help.

Would you like to "re-contrib" your work?

> In, for instance, fe-pqexec.c there are a number of functions, some
> are described as "SUPPORT ROUTINES", while others are "INTERFACE
> ROUTINES".  Both of these are declared in the libpq-fe.h file, so in
> that sense they are all accessible to people using libpq.  On the
> other hand, none of them are mentioned in the ref. section on libpq.
> 
> What should I take as the definitive view on what libpq's public
> interface is, the man page, the include file, the comments in the
> source, or whatever I looks good to me?

The libpq is not extremely well defined.  My understanding of it, is that
you may use any routine beginning with PQ and that the others are for
internal use.  We will try to maintain the semantics of all such routines and
any changes will be broadcast in release notes.

> And, on page 19, the query that generated the list of binary operators
> from the system catalogs doesn't work as written.

Yeah, the error you get is due to a casting problem:

   NOTICE:Jan 30 11:52:02:there is no operator = for types regproc and oid
   NOTICE:Jan 30 11:52:02:You will either have to retype this query using an
   NOTICE:Jan 30 11:52:02:explicit cast, or you will have to define the operator
   WARN:Jan 30 11:52:02:= for regproc and oid using DEFINE OPERATOR

Unfortunately, the type difference involves two attributes (i.e. no constants)
so we can't use :: to perform the cast.

One way around this is to define a procedure to convert the type.  In this
case both RegProcedure and oid are integers so a routine with an RegProcedure 
argument and a return type of oid could just cast and return its input.  The 
query would then be reformulated as:

retrieve (argtype = t1.typname, 
          o.oprname, 
          t0.typname, 
          p.proname,
          ltype=t1.typname, 
          rtype=t2.typname)
    from  p in pg_proc, 
         t0 in pg_type, 
         t1 in pg_type,
         t2 in pg_type, 
          o in pg_operator
    where p.prorettype = t0.oid and 
          RegprocToOid(o.oprcode) = p.oid and
          p.pronargs = 2 and
          o.oprleft = t1.oid and 
          o.oprright = t2.oid

The only difference (besides formatting) is the call to RegprocToOid
providing the needed cast.  It takes some time for the query to execute...
there's nothing like a 4-way join without indices to try your patience.


Jeff Meredith
mer@postgres.berkeley.edu