Re: An amusing MySQL weakness--not!

Поиск
Список
Период
Сортировка
От Leif Biberg Kristensen
Тема Re: An amusing MySQL weakness--not!
Дата
Msg-id 201106271211.21363.leif@solumslekt.org
обсуждение исходный текст
Ответ на Re: An amusing MySQL weakness--not!  (Vincent Veyron <vv.lists@wanadoo.fr>)
Ответы Re: An amusing MySQL weakness--not!  (Vincent Veyron <vv.lists@wanadoo.fr>)
Список pgsql-general
On Sunday 26. June 2011 16.11.06 Vincent Veyron wrote:
> Le dimanche 26 juin 2011 à 00:05 -0700, Darren Duncan a écrit :
> > Michael Nolan wrote:
> >
> > Having real BOOLEAN is just one of the reasons I like Postgres the most.
>
> Would you mind giving an example of where a boolean field would be a win
> over an integer one?
>
> I'm asking this because I frequently wonder what is best for my use; I
> normally query postgres via Perl modules, which don't care about boolean
> (the driver converts t/f to 0/1), but I like to tune my fields properly.

PHP has its own Boolean values TRUE/FALSE, but reads Postgresql Booleans as
't'/'f'. You always have to rely on kludgy konstructs like

if ($pg_bool == 't') then
    $my_bool = TRUE;
elseif ($pg_bool == 'f') then
    $my_bool = FALSE;
else
    $my_bool = NULL;

It's of course much easier to use integer values, but it sucks not to use a
bool when you want a variable that can't be anything but TRUE, FALSE or NULL.

It obfuscates the code to use a var that evaluates to an integer, but in
reality is a Boolean in disguise.

regards, Leif

В списке pgsql-general по дате отправления:

Предыдущее
От: mephysto
Дата:
Сообщение: Custom types as parameter in stored function
Следующее
От: "Albe Laurenz"
Дата:
Сообщение: Re: Reusing cached prepared statement slow after 5 executions