Hi,
On Fri, Feb 13, 2009 at 3:08 AM, Quan Zongliang <quanzongliang@gmail.com> wrote:
> Hi, all
>
> I haven't any experience with libpq. So there are a lot of questions.
>
> When import to db using INSERT statement. Like this:
> res = PQexec(m_conn->connection(), "BEGIN");
> LOOP: res = PQexec(m_conn->connection(), "INSERT INTO ...");
> res = PQexec(m_conn->connection(), "COMMIT");
> If any INSERT statement failed in the middle, the whole transaction is aborted.
> In my plan, the end user can select a number of rows to commit their work.
> (Option: commit every xxx rows.)
> Is there a approach to ingnore error statement and leave current transaction
> in normal status? If it can be did, the program only need log the error and
> go on to deal with left statements.
> Or when encounter a error, stop the deal?
You can use savepoints:
http://www.postgresql.org/docs/8.3/interactive/sql-savepoint.html
> If the end user decide to import with INSERT statement,
> these statements will be sent to db with asynchronous mode:
> LOOP:
> 1: submit statement asynchronous
> 2: generate next statement
> 3: wait for last one to be completed
> 4: log
> goto 1
> Is it OK?
> Or we should use synchronous mode?
Sounds OK. Async is naturally more complex than sync mode, but it does
allow for a more responsive UI.
> First, import function with INSERT statement will be implemented.
> The questions about COPY command will come soon. ^-^
That's the important mode - it'll be much faster than explicit
imports, but will lack the ability to use savepoints or async
processing.
> A discussion:
> In schemas, the pgDatatype had been defined. but it use type-name to recognise type.
> I noticed system types had been defined in server/catalog/pg_type.h:
> #define BOOLOID 16
> #define BYTEAOID 17
> and so on.
> Why don't use these defination in the pgAdmin?
> The judgement with (type==BOOLOID) will get more effective than (name == wxT("boolean")).
Those values may, in theory, change between versions of the server,
and also won't exist for user defined types.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com