[SQL] casting BOOL to somthng

[sad]

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

Re: [SQL] casting BOOL to somthng

[Michael Glaesemann]

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 not a big fan of casts in general so it doesn't 
really bother me too much. If this is something you desire, I believe 
you can use CREATE CAST to make your own cast from boolean to text.

test=# select true::text;
ERROR:  cannot cast type boolean to text
create or replace function bool_to_text (boolean)
returns text
strict
language sql as '
select case
when $1 then \'t\'
else \'f\'
end;
';
create cast (boolean as text)
with function bool_to_text(boolean)
as assignment;
test=# select true::text;
 text
--
 t
(1 row)
You can find more information at

Hope this helps!
Michael Glaesemann
grzm myrealbox com
---(end of broadcast)---
TIP 6: Have you searched our list archives?
  http://archives.postgresql.org

[SQL] colored PL with emacs

[Martin Marques]

Does anyone know of a .el file that can be used with Emacs to get colored 
coding when working with PL/pgSQL?

-- 
 08:40:01 up 8 days, 27 min,  1 user,  load average: 2.53, 2.09, 1.70
-
Martín Marqués| select 'mmarques' || '@' || 'unl.edu.ar'
Centro de Telematica  |  DBA, Programador, Administrador
 Universidad Nacional
  del Litoral
-

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

[SQL] Arbitrary precision arithmatic with pgsql

[Rajesh Kumar Mallah]

Hi,
The docs says that numeric type supports numbers upto
any precision

8.1.2. Arbitrary Precision Numbers
The type numeric can store numbers with up to 1000 digits of precision 
and perform calculations exactly. It is especially recommended for 
storing monetary amounts and other quantities where exactness is 
required. However, the numeric type is very slow compared to the 
floating-point types described in the next section.


However
tradein_clients=# SELECT  cast(2^100 as numeric);
+-+
| numeric |
+-+
| 126765060022823 |
+-+
(1 row)
Time: 1036.063 ms
Naturally there is a loss of information here. So my question is
1. Does the specs not require pgsql to print a warning or info ,
  will it not be considered silient truncation of data.
2. Is there any way to do such calculation using pgsql, i understand
  bc is a better tool for it.
Warm Regards
Rajesh Kumar Mallah.
--
regds
Mallah.
Rajesh Kumar Mallah
+---+
| Tradeindia.com  (3,11,246) Registered Users 	| 
| Indias' Leading B2B eMarketPlace  |
| http://www.tradeindia.com/			|
+---+

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [SQL] colored PL with emacs

[Stephen Quinney]

On Tue, Aug 31, 2004 at 08:42:44AM -0300, Martin Marques wrote:
> Does anyone know of a .el file that can be used with Emacs to get colored 
> coding when working with PL/pgSQL?
> 

Emacs 21.3 (and possibly earlier versions) comes with an SQL mode
which I know has a PostgreSQL keyword highlighting option in the
menu. Just just need:

Meta-x sql-mode
Meta-x global-font-lock-mode

(and possibly select the postgres option in the highlighting bit of
the SQL menu that appears if you are using X)

I hope that helps,

Stephen Quinney



---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match

Re: [SQL] casting BOOL to somthng

[sad]

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)---
TIP 8: explain analyze is your friend

Re: [SQL] Arbitrary precision arithmatic with pgsql

[Michael Glaesemann]

On Aug 31, 2004, at 8:55 PM, Rajesh Kumar Mallah wrote:
The docs says that numeric type supports numbers upto
any precision

However
tradein_clients=# SELECT  cast(2^100 as numeric);

1. Does the specs not require pgsql to print a warning or info ,
  will it not be considered silient truncation of data.
AFAICS, the issue here is not the cast per se, but rather the power 
operation (2^100), which expects a double precision argument. This 
operation happens before the cast.

2. Is there any way to do such calculation using pgsql, i understand
  bc is a better tool for it.
What you need is a power operation for numeric, which I think you'd 
have to write yourself, possibly leveraging one of the procedural 
languages (perhaps pl/perl) to access such an operation (as you 
yourself mentioned). I'm sure you could find an algorithm to port to 
PL/pgsql as well.

Hope this helps.
Michael Glaesemann
grzm myrealbox com
---(end of broadcast)---
TIP 6: Have you searched our list archives?
  http://archives.postgresql.org

Re: [SQL] casting BOOL to somthng

[Geoffrey]

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 would find this useful. 
Don't take me wrong please.  I'm by no means a db expert, but I can't 
see a purpose for such a cast.  Can you provide a reasonable example of 
such usage?

Thanks.
--
Until later, Geoffrey   Registered Linux User #108567
AT&T Certified UNIX System Programmer - 1995
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [SQL] colored PL with emacs

[Martin Marques]

El Mar 31 Ago 2004 09:11, Stephen Quinney escribió:
> On Tue, Aug 31, 2004 at 08:42:44AM -0300, Martin Marques wrote:
> > Does anyone know of a .el file that can be used with Emacs to get colored
> > coding when working with PL/pgSQL?
>
> Emacs 21.3 (and possibly earlier versions) comes with an SQL mode
> which I know has a PostgreSQL keyword highlighting option in the
> menu. Just just need:
>
> Meta-x sql-mode
> Meta-x global-font-lock-mode
>
> (and possibly select the postgres option in the highlighting bit of
> the SQL menu that appears if you are using X)

I have SQL highlighting, but what I want are colors for the PL/pgSQL key 
words. It would make PL programming much easier.

-- 
 09:30:02 up 8 days,  1:17,  2 users,  load average: 0.70, 0.44, 0.54
-
Martín Marqués| select 'mmarques' || '@' || 'unl.edu.ar'
Centro de Telematica  |  DBA, Programador, Administrador
 Universidad Nacional
  del Litoral
-

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [SQL] Arbitrary precision arithmatic with pgsql

[Rajesh Kumar Mallah]

Michael Glaesemann wrote:
On Aug 31, 2004, at 8:55 PM, Rajesh Kumar Mallah wrote:
The docs says that numeric type supports numbers upto
any precision


However
tradein_clients=# SELECT  cast(2^100 as numeric);


1. Does the specs not require pgsql to print a warning or info ,
  will it not be considered silient truncation of data.

AFAICS, the issue here is not the cast per se, but rather the power 
operation (2^100), which expects a double precision argument. This 
operation happens before the cast.

Looks like the power operation of numeric ie, numeric ^ numeric  already 
exists
but it returns a double precision and the accuracy is getting lost. Shud 
numeric
^ numeric  not be returning numeric instead?

Regds
mallah.
tradein_clients=# CREATE TABLE t_a as SELECT  1::numeric ^ 1::numeric  
as col;
SELECT
tradein_clients=# \d t_a
  Table "public.t_a"
++--+---+
| Column |   Type   | Modifiers |
++--+---+
| col| double precision |   |
++--+---+




2. Is there any way to do such calculation using pgsql, i understand
  bc is a better tool for it.

What you need is a power operation for numeric, which I think you'd 
have to write yourself, possibly leveraging one of the procedural 
languages (perhaps pl/perl) to access such an operation (as you 
yourself mentioned). I'm sure you could find an algorithm to port to 
PL/pgsql as well.

Hope this helps.
Michael Glaesemann
grzm myrealbox com
!DSPAM:41346ebe315451222497446!


--
regds
Mallah.
Rajesh Kumar Mallah
+---+
| Tradeindia.com  (3,11,246) Registered Users 	| 
| Indias' Leading B2B eMarketPlace  |
| http://www.tradeindia.com/			|
+---+

---(end of broadcast)---
TIP 6: Have you searched our list archives?
  http://archives.postgresql.org

Re: [SQL] Arbitrary precision arithmatic with pgsql

[Michael Glaesemann]

On Aug 31, 2004, at 9:17 PM, Michael Glaesemann wrote:
What you need is a power operation for numeric, which I think you'd 
have to write yourself,
Looking a little closer, there is a pow() function that takes two 
numeric arguments and returns numeric.


test=# select pow(2::numeric,100::numeric);
   pow
--
 1267650600228229401496703205376.
(1 row)
Sorry for the misinformation.
If you'd like, I think you can overload the ^ operator to work on 
numeric as well if you don't want to use pow(). See the following page 
for more information.


Michael Glaesemann
grzm myrealbox com
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [SQL] Arbitrary precision arithmatic with pgsql

[Rajesh Kumar Mallah]

Michael Glaesemann wrote:
On Aug 31, 2004, at 9:17 PM, Michael Glaesemann wrote:
What you need is a power operation for numeric, which I think you'd 
have to write yourself,

Looking a little closer, there is a pow() function that takes two 
numeric arguments and returns numeric.


test=# select pow(2::numeric,100::numeric);
   pow
--
 1267650600228229401496703205376.
(1 row)
Sorry for the misinformation.
If you'd like, I think you can overload the ^ operator to work on 
numeric as well if you don't want to use pow(). See the following page 
for more information.



Yep thats cool.  Thanks for the research!
but i still wonder if a warning or info message were
appropriate at some stage so that people do not confuse it
with sielent loss of accuracy . I know this example is *not* a
case of where postgresql is truncating data at the insert level
(like mysql does) but at the calculation level.
regds
mallah.


regds
mallah.

Michael Glaesemann
grzm myrealbox com
!DSPAM:4134745e87571738116768!


--
regds
Mallah.
Rajesh Kumar Mallah
+---+
| Tradeindia.com  (3,11,246) Registered Users 	| 
| Indias' Leading B2B eMarketPlace  |
| http://www.tradeindia.com/			|
+---+

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [SQL] casting BOOL to somthng

[Michael Glaesemann]

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' as a representation for the 
BOOLEAN value TRUE, but some people might want it to return 'TRUE' or 
'true' or other representations. Picking one is perhaps arbitrary.

In a similar vein, some people would like to cast BOOLEAN to INTEGER, 
as often BOOLEAN TRUE and BOOLEAN FALSE are represented as INTEGER 1 
and INTEGER 0, respectively, in some systems. However, other systems 
use different INTEGER representations such as INTEGER 1 and INTEGER -1 
for BOOLEAN TRUE and FALSE, respectively. Again, the choice of how to 
cast BOOLEAN to INTEGER is kind of arbitrary.

Luckily PostgreSQL provides convenient ways of making user-defined 
casts.

Just my thoughts.
Michael Glaesemann
grzm myrealbox com
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
 subscribe-nomail command to [EMAIL PROTECTED] so that your
 message can get through to the mailing list cleanly

Re: [SQL] Arbitrary precision arithmatic with pgsql

[Jan Wieck]

On 8/31/2004 9:15 AM, Rajesh Kumar Mallah wrote:
Michael Glaesemann wrote:
On Aug 31, 2004, at 9:17 PM, Michael Glaesemann wrote:
What you need is a power operation for numeric, which I think you'd 
have to write yourself,

Looking a little closer, there is a pow() function that takes two 
numeric arguments and returns numeric.


test=# select pow(2::numeric,100::numeric);
   pow
--
 1267650600228229401496703205376.
(1 row)
Sorry for the misinformation.
If you'd like, I think you can overload the ^ operator to work on 
numeric as well if you don't want to use pow(). See the following page 
for more information.



Yep thats cool.  Thanks for the research!
but i still wonder if a warning or info message were
appropriate at some stage so that people do not confuse it
with sielent loss of accuracy . I know this example is *not* a
case of where postgresql is truncating data at the insert level
(like mysql does) but at the calculation level.
I agree that doing
select 2::numeric ^ 100;
should emit some sort of a warning. Because what happens here is that 
the numeric value is degraded to a float8 in order to use the operator.

I don't think that
select 2 ^ 100;
should emit the same warning.
Jan
--
#==#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.  #
#== [EMAIL PROTECTED] #
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
 joining column's datatypes do not match

Re: [SQL] Arbitrary precision arithmatic with pgsql

[Michael Glaesemann]

On Aug 31, 2004, at 11:18 PM, Jan Wieck wrote:
I agree that doing
select 2::numeric ^ 100;
should emit some sort of a warning. Because what happens here is that 
the numeric value is degraded to a float8 in order to use the 
operator.
Would this be solved by overloading the ^ operator with the 
pow(numeric,numeric) function? Would the 100 be cast INT -> NUMERIC?

Michael Glaesemann
grzm myrealbox com
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [SQL] Arbitrary precision arithmatic with pgsql

[Tom Lane]

Jan Wieck <[EMAIL PROTECTED]> writes:
> I agree that doing
>  select 2::numeric ^ 100;
> should emit some sort of a warning.

I do not.  The conversion of 2::numeric to float is exact, so AFAICS
the only way to do that would be to make *every* coercion of numeric to
float emit a warning.  This is not a reasonable response to the fact
that Rajesh is unaware of the set of available operators.  Moreover
it would essentially break float constants (since "2.0" starts life
as numeric and is only cast to float when the context demands).

I'd be in favor of adding a numeric^numeric operator to ease access to
the existing pow() code, but I'm not sure this makes the issue go away
entirely.  It looks like "select 2 ^ 100" would still default to being
a float operation.

regression=# create operator ^ (procedure=pow, leftarg=numeric, rightarg=numeric);
CREATE OPERATOR
regression=# select 2::numeric ^ 100;
 ?column?
--
 1267650600228229401496703205376.
(1 row)

regression=# select 2 ^ 100;
   ?column?
--
 1.26765060022823e+30
(1 row)

regression=# select 2.0 ^ 100;
 ?column?
--
 1267650600228229401496703205376.
(1 row)


regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [SQL] Arbitrary precision arithmatic with pgsql

[Jan Wieck]

On 8/31/2004 11:04 AM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
I agree that doing
 select 2::numeric ^ 100;
should emit some sort of a warning.
I do not.  The conversion of 2::numeric to float is exact, so AFAICS
the only way to do that would be to make *every* coercion of numeric to
float emit a warning.  This is not a reasonable response to the fact
that Rajesh is unaware of the set of available operators.  Moreover
it would essentially break float constants (since "2.0" starts life
as numeric and is only cast to float when the context demands).
I thought they start life as an unknown literal ... that of course 
changes things.

Jan
I'd be in favor of adding a numeric^numeric operator to ease access to
the existing pow() code, but I'm not sure this makes the issue go away
entirely.  It looks like "select 2 ^ 100" would still default to being
a float operation.
regression=# create operator ^ (procedure=pow, leftarg=numeric, rightarg=numeric);
CREATE OPERATOR
regression=# select 2::numeric ^ 100;
 ?column?
--
 1267650600228229401496703205376.
(1 row)
regression=# select 2 ^ 100;
   ?column?
--
 1.26765060022823e+30
(1 row)
regression=# select 2.0 ^ 100;
 ?column?
--
 1267650600228229401496703205376.
(1 row)
			regards, tom lane

--
#==#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.  #
#== [EMAIL PROTECTED] #
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [SQL] colored PL with emacs

[Manuel Sugawara]

Martin Marques <[EMAIL PROTECTED]> writes:

> I have SQL highlighting, but what I want are colors for the PL/pgSQL
> key words. It would make PL programming much easier.

Since the Pl/PgSQL code is quoted (x)emacs paints the whole thing
using the string face. Delete one of the apostrophes delimiting the
code while editing and you should get some highlighting.

Regards,
Manuel.

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [SQL] colored PL with emacs

[Josh Berkus]

Martin,

> > I have SQL highlighting, but what I want are colors for the PL/pgSQL
> > key words. It would make PL programming much easier.

KDE's Kate has PostgreSQL highlighting.  Unfortunately, the config is XML so 
it's not transferrable to Emacs ...

-- 
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [SQL] colored PL with emacs

[Greg Sabino Mullane]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
 
> I have SQL highlighting, but what I want are colors for the PL/pgSQL
> key words. It would make PL programming much easier.
 
There's nothing out there. but writing one is on my long-term TODO list.
 
> KDE's Kate has PostgreSQL highlighting.  Unfortunately, the config
> is XML so it's not transferrable to Emacs ...
 
Send me (or the list, of it's short) a copy, I'll see if I can
do anything with it.
 
- --
Greg Sabino Mullane [EMAIL PROTECTED]
PGP Key: 0x14964AC8 200408311920
 
-BEGIN PGP SIGNATURE-
 
iD8DBQFBNQfgvJuQZxSWSsgRAl8CAJ9bmcZG/pTx9Pg5H+sjxT77RbWsLwCg0b1u
oB/ZJocEC42tdahkIrlBIZs=
=eF8t
-END PGP SIGNATURE-



---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [SQL] casting BOOL to somthng

[sad]

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 predefined casts for INT and FLOAT..
>
> I'd like to understand in what context you would find this useful.
> Don't take me wrong please.  I'm by no means a db expert, but I can't
> see a purpose for such a cast.  Can you provide a reasonable example of
> such usage?

Yes i can. 
look:

CREATE TABLE t (a int, b text, c bool);

SELECT 'the row is: a='||a::TEXT||' b='||b||' c='||c::TEXT FROM t;


---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [SQL] casting BOOL to somthng

[sad]

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 the proper textual representation of
> BOOLEAN? True, PostgreSQL returns 't' as a representation for the
> BOOLEAN value TRUE, but some people might want it to return 'TRUE' or
> 'true' or other representations. Picking one is perhaps arbitrary.

There are many (infinite number) of INT representations,
"Picking one is perhaps arbitrary." But you poke one and using it.

If some one wants another representation you ask him do define his own 
function and use it instead of cast. And you are right. In your system 
integers textully represented as you define. Just define one representation 
for boolean and leave the rest for user definition.


---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match

Re: [SQL] casting BOOL to somthng

[Stephan Szabo]

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..
> >
> > I think the main reason is what is the proper textual representation of
> > BOOLEAN? True, PostgreSQL returns 't' as a representation for the
> > BOOLEAN value TRUE, but some people might want it to return 'TRUE' or
> > 'true' or other representations. Picking one is perhaps arbitrary.
>
> There are many (infinite number) of INT representations,
> "Picking one is perhaps arbitrary." But you poke one and using it.

There's a fairly accepted convention for integer representations.
There's no such convention for boolean representations.


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [SQL] casting BOOL to somthng

[sad]

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 ?
> > > > 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' as a representation for the
> > > BOOLEAN value TRUE, but some people might want it to return 'TRUE' or
> > > 'true' or other representations. Picking one is perhaps arbitrary.
> >
> > There are many (infinite number) of INT representations,
> > "Picking one is perhaps arbitrary." But you poke one and using it.
>
> 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 ?!



---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [SQL] casting BOOL to somthng

[Michael Glaesemann]

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 print *something* you can't see it?
Michael Glaesemann
grzm myrealbox com
---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [SQL] casting BOOL to somthng

[sad]

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 why do you print its value on a screen ?!
>
> Perhaps because if you don't print *something* you can't see it?

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?


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [SQL] casting BOOL to somthng

[Peter Eisentraut]

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 it varies.  If you use libpq, you get a 
character 't' or 'f', if you use ECPG you get a C bool (int) datum, if 
you use JDBC, you get a Java bool value, etc.  psql uses libpq, so you 
see 't' or 'f'.  MS Access maybe uses ODBC and you might see a checkbox 
or something.  It's part of the interface definition.

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 universal and obvious as the well-known 
correspondence between character strings and numbers.  We could pick 
one arbitrary correspondence and implement it, and if we did we would 
probably pick one that is consistent with the mapping used by libpq and 
other frontends.  But doing that gains no functionality, so why bother?

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/


---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org