Re: storing true/false, was: Comments on adding more - Mailing list pgsql-jdbc

From Dave Cramer
Subject Re: storing true/false, was: Comments on adding more
Date
Msg-id 1075916805.1599.75.camel@localhost.localdomain
Whole thread Raw
In response to Re: storing true/false, was: Comments on adding more connection  ("scott.marlowe" <scott.marlowe@ihs.com>)
List pgsql-jdbc
I am, but we can't just go making up our own version of true and false,
what this is referring to is storing a true/false into an integer and
interpreting it as such from the getBoolean()/setBoolean() methods

DAve
On Wed, 2004-02-04 at 12:20, scott.marlowe wrote:
> Sorry, since this is the jdbc list I kinda assumed you were talking about
> how jdbc was storing true and false...
>
> On 4 Feb 2004, Dave Cramer wrote:
>
> > Scott,
> >
> > This is a backend thing, 'f' 't' are boolean values for the backend, we
> > don't attempt to parse and change things.
> >
> > Dave
> > On Wed, 2004-02-04 at 11:36, scott.marlowe wrote:
> > > On 3 Feb 2004, Dave Cramer wrote:
> > >
> > > > Kris,
> > > >
> > > > I also have a few more,
> > > >
> > > > one to change the behaviour for handling booleans, from inserting 't',
> > > > 'f' to inserting '1', and '0'
> > > >
> > > > I think one way to deal with this on a non-connection basis is to use
> > > > System properties, this won't work for the schema search path, but would
> > > > work for most others.
> > > >
> > > > How do the other drivers handle this?
> > >
> > > Why not store TRUE and FALSE with no ticks.  Like DEFAULT and NULL they're
> > > keywords that mean the exact thing, not an internal representation that
> > > might change over time.
> > >
> > > insert into table1 (tf) values (TRUE);
> > >
> >
>
--
Dave Cramer
519 939 0336
ICQ # 14675561


pgsql-jdbc by date:

Previous
From: "scott.marlowe"
Date:
Subject: Re: storing true/false, was: Comments on adding more connection
Next
From: Paul Thomas
Date:
Subject: Re: Comments on adding more connection URL parameters.