Re: OID-problem: metadata: use of TableGen O/R-mapper

Thanks much for your respective responses.

The relevant decision-maker(s) on my end will presumably consider your feedback and
tell me how they want me to handle this issue.

This morning, the precision-issue occurred to me. I proceeded to develop a solution
involving "substring":
"substring(current_timestamp, 0, 20)"
that seemed to truncate so as to leave off the entire fractional part of the
timestamp, which I believed is the issue. Something similar is done in the
DAO-base-class used by TableGen, but only for Oracle.

You seem to be saying something slightly different: namely, that there's a degree of
precision (in terms of fractions of a second) that the stable driver does support,
instead of not supporting any fractional part. Do I understand this correctly?

Also, is there any problem with putting CURRENT_TIMESTAMP into a timestamp(2) field?
That seems to be a case of a kind of "cast required, lest loss of precision" issue.
Not so? If so, would my substring approach be preferred (or required)?

The CURRENT_TIMESTAMP, in this case, is being used in a trigger (for INSERT and UPDATE
timestamping).

Larry LeFever

Dave Cramer wrote:

> Larry,
>
> As co-maintainer I second Barry's suggestion. I certainly am aware of
> many more bugs that were fixed than we have possibly created. I also
> routinely use beta drivers in production.
>
> Dave
> On Fri, 2002-11-15 at 13:36, Barry Lind wrote:
> > Larry,
> >
> > Larry LeFever wrote:
> > >
> > > I didn't realize until just today that the latest stable version of the driver
> > > seems to have a problem with TIMESTAMP (or do I have a
> > > configuration-problem?).
> > >
> >
> > The problem is that the 7.2 driver has a bug with understanding the
> > extra precision in the seconds. In 7.1 the database only really
> > supported 9.99 for precision, but 7.2 can support upto 9.999999. One
> > way to work around this problem is to create your columns with less
> > precision. So instead of:
> > create table foo (col_a timestamp)
> > use:
> > create table foo (col_a timestamp(2)) - where two is two decimal digits
> > of precision
> >
> > >
> > > I'm reluctant to use third-party beta-code on the current project; it handles
> > > "other people's money" and financial accounts.
> > >
> >
> > I understand your reluctance, but 7.3 goes RC1 today. And I personally
> > feel that the 7.3 driver is better than the 7.2 version. And I am
> > currently running it on one production system. (Of course as a
> > maintainer of the driver I probably should be using in it production
> > before anyone else :-)
> >
> > > BTW, if this project could count on really speedy bug-fix responses from
> > > postgres-developers (or specifically from postgres JDBC-driver developers),
> > > perhaps use of 7.3 beta 3 in our production version would be worth the risk --
> > > though that would ultimately not be for me to say.
> >
> > If you go the 7.3 route, use something more current thant beta3. There
> > have been some fixes since beta3, one of which is very important. I
> > will try to get RC1 builds posted to the website over the weekend, else
> > you can build from CVS.
> >
> > thanks,
> > --Barry
> >
> >
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
> --
> Dave Cramer <Dave(at)micro-automation(dot)net>