[HACKERS] database read/write from applications code Request for advice

2004-05-05 Thread terr
I am wondering if there is a simple way to implement a read() blah and write() blah 
function to a database.

The application I'm looking at is very simple and this is all that is required.  In 
the past I used a cursor - did the select, then retrieved the records one at a time.

Any suggestions?  I would prefer to not re-map each feild with each call and if I use 
the equivalent of pro*c it generates over 1000 parameters into the call - which is 
crasy.

A function that binds the variables from the calling program would be acceptable.  For 
instance we might have pgbind(myCfield, fieldType, sizeof(myCfield) ...) or something 
along this line.

Thanx.


---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org


[HACKERS] talking to postgresql from C/C++

2003-03-07 Thread terr

---BeginMessage---
I've been trying to get information on a programming interface to the database.  Over 
the last while Dave Page and I have emailed each other.  Dave has suggested I join the 
hacker maillist.

Thus I am forwarding the communication I sent to Dave.  I hope this is approriated in 
this channel.  If not please advise where I should go.


I'll look forward to some clarification about what is or is not available by way of 
talking to the database from languages like C.

Thanks.

Terrell Larson


--3Pql8miugIZX0722
Content-Type: message/rfc822
Content-Disposition: inline

Date: Fri, 7 Mar 2003 04:18:45 -0700
From: terr
To: Dave Page [EMAIL PROTECTED]
Subject: Re: Fwd: ODBC docs
Message-ID: [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: [EMAIL PROTECTED]; from [EMAIL PROTECTED] on Fri, Mar 07, 2003 at 
08:49:00AM -


Over at M$, I see the following:

* SQQLAllocConnect Function
* SQLAllocEnv Function
* SQLAllocHandle Function
* SQLAllocStmt Function
* SQLBindCol Function
* SQLBindParameter Function
* SQLBrowseConnect Function
* SQLBulkOperations Function
* SQLCancel Function
* SQLCloseCursor Function
* SQLColAttribute Function
* SQLColAttributes Function
* SQLColumnPrivileges Function
* SQLColumns Function
* SQLConnect Function
* SQLCopyDesc Function
* SQLDataSources Function
* SQLDescribeCol Function
* SQLDescribeParam Function
* SQLDisconnect Function
* SQLDriverConnect Function
* SQLDrivers Function
* SQLEndTran Function
* SQLError Function
* SQLExecDirect Function
* SQLExecute Function
* SQLExtendedFetch Function
* SQLFetch Function
* SQLFetchScroll Function
* SQLForeignKeys Function
* SQLFreeConnect Function
* SQLFreeEnv Function
* SQLFreeHandle Function
* SQLFreeStmt Function
* SQLGetConnectAttr Function
* SQLGetConnectOption Function
* SQLGetCursorName Function
* SQLGetData Function
* SQLGetDescField Function
* SQLGetDescRec Function
* SQLGetDiagField Function
* SQLGetDiagRec Function
* SQLGetEnvAttr Function
* SQLGetFunctions Function
* SQLGetInfo Function
* SQLGetStmtAttr Function
* SQLGetStmtOption Function
* SQLGetTypeInfo Function
* SQLMoreResults Function
* SQLNativeSql Function
* SQLNumParams Function
* SQLNumResultCols Function
* SQLParamData Function
* SQLParamOptions Function
* SQLPrepare Function
* SQLPrimaryKeys Function
* SQLProcedureColumns Function
* SQLProcedures Function
* SQLPutData Function
* SQLRowCount Function
* SQLSetConnectAttr Function
* SQLSetConnectOption Function
* SQLSetCursorName Function
* SQLSetDescField Function
* SQLSetDescRec Function
* SQLSetEnvAttr Function
* SQLSetParam Function
* SQLSetPos Function
* SQLSetScrollOptions Function
* SQLSetStmtAttr Function
* SQLSetStmtOption Function
* SQLSpecialColumns Function
* SQLStatistics Function
* SQLTablePrivileges Function
* SQLTables Function
* SQLTransact Function


This looks like the API.  Thanks.  Now - IMHO we should have these docs on our 
website instead of having to rely on M$.  

It this is truely not currently available I may be able to start flanging something 
up.  I suspect that there may be bits and peices around... perhaps the whole thing.

Also - I really want to find out how some of these functions are implemented.  The 
problem I'm looking at is that: 

(1) if I use ecpg then I get over 1000 parameters stuffed into some of the calls.  
This is just plain NUTZ.  Aside from it being virtually insane to try to pass this 
many parameters to a function call, it makes absolutly no sense to stack over 1000 
addresses, call the interface, find out the row is not present, tear down the 
addresses, build the row (about 100 fields), stack over 1000 addresses bak up, call 
the interface to post the row, and tear the stack back down only to do this all over 
again for the next row.

Passing this many addresses is so NUTZ that when I popped into the #C developers group 
on Freenode and also the #debian channels and asked if anyone knew the maximum number 
of parameters one could pass into a function call - that they started to abuse me!  
haha.  Some must have thought I was a 1st year uni student without much common sense.  
What can I say.  IMHO 1000+ parameters is an embarrasment.

(2) if I use libpg then I apparently have to map each and every column for each row 
over and over, column by column for each row in a manner that is very similar to (1).  
None of the columns change between calls to the database and none of the variables 
move around. (in this case the buffers are statically mapped - by design)  I should be 
able to build up a table of the mapping of MY C