Subject: libpq philosophy, perl and Postgres...

From: George Hartzell <[email-masked]>
Date: Wed, 29 Jan 92 19:59:55 -0800

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

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.

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?

While I'm at it, on page 83 of the reference (in libpq), the function
called PQnames should be PQpnames as far as I can tell.

Also, the ref section for monitor(1) describes a -A option, while the
source seems to use a -T.

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

g.

George Hartzell                                         voice: (415) 725-7421
Stanford Yeast Genome Project                           fax:   (415) 723-7016
Stanford School of Medicine, Rm S337   email: [email-masked]
Stanford, CA 94305-5120

---

From: postarch (Postgres Mailing Archive)
Date: Thu, 30 Jan 92 12:41:59 PST

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

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

> begin/end), but I need some philosophical help.

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

> 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.

> 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
[email-masked]