agora inbox for postgres@postgres.berkeley.edu
help / color / mirror / Atom feedsorry
3+ messages / 3 participants
[nested] [flat]
* sorry
@ 1992-04-08 20:44 Christoph Kukulies <kuku@acds.physik.rwth-aachen.de>
0 siblings, 0 replies; 3+ messages in thread
From: Christoph Kukulies @ 1992-04-08 20:44 UTC (permalink / raw)
To: legacy
Excuse the double posting on bandwidth wasting. I wanted to hit the
guy who posted this wonderful banner signature but missed him
twice. So I better stop now wasting bandwidth.
--Chris
^ permalink raw reply [nested|flat] 3+ messages in thread
* sorry..
@ 1994-10-14 10:27 Praveen Mamnani <pmamnani@cs.nmsu.edu>
1994-10-15 21:54 ` Re: sorry.. Robert.Patrick@cs.cmu.edu
0 siblings, 1 reply; 3+ messages in thread
From: Praveen Mamnani @ 1994-10-14 10:27 UTC (permalink / raw)
To: legacy; +Cc: pmamnani@nmsu.edu
I am sorry, by mistake the last message was sent in a wrong format.
The following is my original message..
I had some embedded SQL programs that I was converting to PQL,
In SQL one can do a SELECT <field name>. In PQL one can retrieve a
field in a similar manner :
retrieve (result = EMP.salary)
where EMP.name = "Bill" \g
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".
So every time when I have to retrieve a specific field in a class, I
have to go through this process, instead of just specifying the field
name and the "where" condition (as done in monitor).
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?
your help would be greatly appriciated.
Praveen.
==============================================================================
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.
==============================================================================
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: sorry..
1994-10-14 10:27 sorry.. Praveen Mamnani <pmamnani@cs.nmsu.edu>
@ 1994-10-15 21:54 ` Robert.Patrick@cs.cmu.edu
0 siblings, 0 replies; 3+ messages in thread
From: Robert.Patrick@cs.cmu.edu @ 1994-10-15 21:54 UTC (permalink / raw)
To: legacy; Praveen Mamnani <pmamnani@cs.nmsu.edu>; +Cc: pmamnani@nmsu.EDU
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.
==============================================================================
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~1994-10-15 21:54 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1992-04-08 20:44 sorry Christoph Kukulies <kuku@acds.physik.rwth-aachen.de>
1994-10-14 10:27 sorry.. Praveen Mamnani <pmamnani@cs.nmsu.edu>
1994-10-15 21:54 ` Re: sorry.. Robert.Patrick@cs.cmu.edu
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox