On Wed, 1 Sep 2004, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > The cast to text, however, is part of the data model, and it has to be
> > both natural and universal. I think you agree that there is no
> > universal, obvious correspondence between character strings and boo
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The cast to text, however, is part of the data model, and it has to be
> both natural and universal. I think you agree that there is no
> universal, obvious correspondence between character strings and boolean
> values, at least not nearly as unive
sad wrote:
On Wednesday 01 September 2004 10:38, Michael Glaesemann wrote:
On Sep 1, 2004, at 2:41 PM, sad wrote:
On Wednesday 01 September 2004 09:24, Stephan Szabo wrote:
There's a fairly accepted convention for integer representations.
There's no such convention for boolean representations.
then
On Wed, 1 Sep 2004, sad wrote:
> > There's a difference between an output function and a cast to text.
> > One gives you an external representation of the data for end use. The
> > other gives you an internal representation for manipulation.
>
> And at the same time
>
> 't'::TEXT can be casted t
> There's a difference between an output function and a cast to text.
> One gives you an external representation of the data for end use. The
> other gives you an internal representation for manipulation.
And at the same time
't'::TEXT can be casted to BOOL
't'::BOOL
but reverse.
On Wed, 1 Sep 2004, sad wrote:
> On Wednesday 01 September 2004 09:24, Stephan Szabo wrote:
> > On Wed, 1 Sep 2004, sad wrote:
> > > On Tuesday 31 August 2004 17:49, Michael Glaesemann wrote:
> > > > On Aug 31, 2004, at 8:24 PM, sad wrote:
> > > > > and i am still desire to know _WHY_ there are n
On Sep 1, 2004, at 2:55 PM, sad wrote:
On Wednesday 01 September 2004 10:38, Michael Glaesemann wrote:
On Sep 1, 2004, at 2:41 PM, sad wrote:
On Wednesday 01 September 2004 09:24, Stephan Szabo wrote:
There's a fairly accepted convention for integer representations.
There's no such convention for b
sad wrote:
> since you printed it you poke a convention (of casting to string)
>
> if you can print it on screen why not to print it in string?
Allow me an attempt at a philosophical explanation:
The external representation to the API is arbitrary, because it's part
of the API specification, and
On Wednesday 01 September 2004 10:38, Michael Glaesemann wrote:
> On Sep 1, 2004, at 2:41 PM, sad wrote:
> > On Wednesday 01 September 2004 09:24, Stephan Szabo wrote:
> >> There's a fairly accepted convention for integer representations.
> >> There's no such convention for boolean representations.
On Sep 1, 2004, at 2:41 PM, sad wrote:
On Wednesday 01 September 2004 09:24, Stephan Szabo wrote:
There's a fairly accepted convention for integer representations.
There's no such convention for boolean representations.
then why do you print its value on a screen ?!
Perhaps because if you don't pri
On Wednesday 01 September 2004 09:24, Stephan Szabo wrote:
> On Wed, 1 Sep 2004, sad wrote:
> > On Tuesday 31 August 2004 17:49, Michael Glaesemann wrote:
> > > On Aug 31, 2004, at 8:24 PM, sad wrote:
> > > > and i am still desire to know _WHY_ there are no predefined cast for
> > > > BOOL ?
> > >
On Wed, 1 Sep 2004, sad wrote:
> On Tuesday 31 August 2004 17:49, Michael Glaesemann wrote:
> > On Aug 31, 2004, at 8:24 PM, sad wrote:
> > > and i am still desire to know _WHY_ there are no predefined cast for
> > > BOOL ?
> > > and at the same time there are predefined casts for INT and FLOAT...
On Tuesday 31 August 2004 17:49, Michael Glaesemann wrote:
> On Aug 31, 2004, at 8:24 PM, sad wrote:
> > and i am still desire to know _WHY_ there are no predefined cast for
> > BOOL ?
> > and at the same time there are predefined casts for INT and FLOAT..
>
> I think the main reason is what is
On Tuesday 31 August 2004 16:22, Geoffrey wrote:
> sad wrote:
> > you wrote:
> >>you can use CREATE CAST to make your own cast from boolean to text.
> >
> > thnx it helps.
> >
> > and i am still desire to know _WHY_ there are no predefined cast for BOOL
> > ? and at the same time there are predefin
On Aug 31, 2004, at 8:24 PM, sad wrote:
and i am still desire to know _WHY_ there are no predefined cast for
BOOL ?
and at the same time there are predefined casts for INT and FLOAT..
I think the main reason is what is the proper textual representation of
BOOLEAN? True, PostgreSQL returns 't'
sad wrote:
you wrote:
you can use CREATE CAST to make your own cast from boolean to text.
thnx it helps.
and i am still desire to know _WHY_ there are no predefined cast for BOOL ?
and at the same time there are predefined casts for INT and FLOAT..
I'd like to understand in what context you w
you wrote:
> you can use CREATE CAST to make your own cast from boolean to text.
thnx it helps.
and i am still desire to know _WHY_ there are no predefined cast for BOOL ?
and at the same time there are predefined casts for INT and FLOAT..
---(end of broadcast)
On Aug 31, 2004, at 6:06 PM, sad wrote:
why BOOL can not be casted to TEXT
nevertheless BOOL has a textual (output) representation 't' and
'f' letters
why not to use this fact to define cast to TEXT ?
I'm not sure of the reason why there isn't a built-in cast from boolean
to text, though I'm
hello
why BOOL can not be casted to TEXT
...nevertheless BOOL has a textual (output) representation 't' and 'f' letters
why not to use this fact to define cast to TEXT ?
---(end of broadcast)---
TIP 8: explain analyze is your friend
19 matches
Mail list logo
