Re: [HACKERS] how to deal with sparse/to-be populated tables - Mailing list pgsql-hackers

From Chris Bitmead
Subject Re: [HACKERS] how to deal with sparse/to-be populated tables
Date
Msg-id 389A26F0.E2742DF1@nimrod.itg.telecom.com.au
Whole thread Raw
In response to how to deal with sparse/to-be populated tables  (Alfred Perlstein <bright@wintelcom.net>)
Responses Re: [HACKERS] how to deal with sparse/to-be populated tables  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Alfred Perlstein wrote:
> > There are two things you can do...
> >
> > 1) remember if a record came out of the database in the first place
> > with a flag. This is what an object database would do.
> 
> You mean implement an LRU cache outside the database, I've thought about
> this and could actually do it, the thing that bugs me about it is
> that i'm essentially trying to outsmart a 10+ year (guessing) old
> piece of software with something that I'd have to hack up in a
> matter of days.

Well, you only gave a small code snippet, I don't know how your app
works.

But often you retrieve tuples from the database and populate a C struct
or something...

struct Person {char *firstname;char *lastname;
};

What I'm saying is, if you are already doing something like this, then
just add one more boolean to say if it is a new or existing Person.
If you are not doing anything like this currently then it's not an
option.

Alternatively wait for my ODBMS features :-)

> This is what I was thinking, the problem then becomes that I'm
> not aware of way to determine the error with
> some degree of accuracy so that I don't mistake:
>  insert error because of duplication
> with:
>  insert error because of database connectivity (or other factors)
> 
> Is it possible to do that?  I guess I could parse the error responce
> from the backend, but maybe there's an easier/more-correct way?

Hmm. Doesn't PostgreSQL have a big list of error codes? I don't think
it does, I've never seen one. There should be a way to get error
codes without comparing strings. Should this be on the TODO?


pgsql-hackers by date:

Previous
From: "Ross J. Reedstrom"
Date:
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
Next
From: Mark Hollomon
Date:
Subject: docs and createlang patch for plperl