agora inbox for postgres@postgres.berkeley.edu  

help / color / mirror / Atom feed

From: Robert.Patrick@cs.cmu.edu
To: postgres@postgres.Berkeley.EDU
To: Praveen Mamnani <pmamnani@cs.nmsu.edu>
Cc: pmamnani@nmsu.EDU
Subject: Re: sorry..
Date: Sat, 15 Oct 1994 17:54:14 -0400 (EDT)
Message-ID: <gic4y6m00hMdE1MZEU@cs.cmu.edu> (raw)
In-Reply-To: <9410142327.AA01058@chaperito>
References: <9410142327.AA01058@chaperito>

Excerpts from internet.postgres: 14-Oct-94 sorry.. Praveen
Mamnani@cs.nmsu. (1599) 

> But when using libpq, executing such simpler queries is not easy. One
> has to get the instance in a portal buffer then apply some more
> functions (such as PQnfields(), PQgetvalue(), etc.) to get to that
> particular field (EMP.salary), for that particular employer "Bill". 

I think you are confused.  The query is executed through libpq just the
same as it is in the monitor.  The only difference is that the monitor
has some additional code that prints the results to stdout.  The
PQnfields() function is only there for your convenience in case you do
not know how many fields the query will return.  PQgetvalue() is there
so that you can get the value of each field in each tuple.  

In your example query, assuming that there is only one tuple which
matches your where condition,  the only thing that should be in the
portal is the single field "result" with the single tuple containing the
value of the salary for Bill. 

Excerpts from internet.postgres: 14-Oct-94 sorry.. Praveen
Mamnani@cs.nmsu. (1599) 

>         In the programs that I am converting I have many-many retrieve
> statements, and for each retrieve, I will have to go through all this
> process for each different field in a different class. Is there another
> way or an easier way to do such retrieve statments when using libpq? 

In embedded SQL, you still have to go through a similar, although
somewhat different, process.  Normally, in embedded SQL, you execute a
query and then ask the interface how much memory is required to store
each tuple returned.  Then, you allocate the memory required for one (or
all) of the tuples and use a cursor to fetch the data into the allocated
memory.  

If you are accustomed to the embedded SQL interface, it may take a
little while to get used to libpq but I think you will find that there
isn't that much difference.  The major difference is that most (if not
all) embedded SQL interfaces provide a pre-proccessor which translates
your embedded SQL calls into the appropriate function calls for you.  In
other words, the raw C function calls are hidden from the user. 

Cheers, 
Robert 






 

==============================================================================
   To add/remove yourself to/from the POSTGRES mailing list: send mail with 
   the subject line ADD or DEL to "postgres-request@postgres.Berkeley.EDU"

   If this fails, send mail to "post_questions@postgres.Berkeley.EDU" and
   a human will deal with it.  DO NOT post to the "postgres" mailing list.
==============================================================================

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: postgres@postgres.berkeley.edu
  Cc: Robert.Patrick@cs.cmu.edu, pmamnani@cs.nmsu.edu, pmamnani@nmsu.EDU
  Subject: Re: sorry..
  In-Reply-To: <gic4y6m00hMdE1MZEU@cs.cmu.edu>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox