Alexandre GRAIL wrote:
> On 24/01/2019 12:45, Geoff Winkless wrote:
> > My own opinion is that non-0 should implicitly cast as true and 0
> > should cast as false. I just run
> >
> > UPDATE pg_cast SET castcontext = 'i' WHERE oid IN (
> > SELECT c.oid
> > FROM pg_cast c
> > inner join pg_typ
On 24/01/2019 17:19, Geoff Winkless wrote:
Like you say it is a matter of opinion. The projects opinion is here:
https://www.postgresql.org/docs/11/datatype-boolean.html
and it works for me.
And you're welcome to it. I'm not arguing for it changing. I'm simply
stating that I'm very pleased th
On 24/01/2019 12:45, Geoff Winkless wrote:
My own opinion is that non-0 should implicitly cast as true and 0
should cast as false. I just run
UPDATE pg_cast SET castcontext = 'i' WHERE oid IN (
SELECT c.oid
FROM pg_cast c
inner join pg_type src ON src.oid = c.castsource
inner join pg_typ
On Thu, 24 Jan 2019 at 16:00, Adrian Klaver wrote:
> People are going to make mistakes that is a given. Eliminating a boolean
> test is not going to change that.
I still think that if you've got to the point where you're actually
part-way through writing a clause you're unlikely to forget to
comp
On 1/24/19 7:48 AM, Geoff Winkless wrote:
On Thu, 24 Jan 2019 at 15:40, Adrian Klaver wrote:
delete from delete_test where
and then forget the 'field =' part. Though my more common mistake along
that line is:
delete from delete_test;
At any rate, if it can be done it will be done.
If you f
On Thu, 24 Jan 2019 at 15:40, Adrian Klaver wrote:
> delete from delete_test where
>
> and then forget the 'field =' part. Though my more common mistake along
> that line is:
>
> delete from delete_test;
>
> At any rate, if it can be done it will be done.
If you follow that logic, then having a s
On 1/24/19 7:32 AM, Geoff Winkless wrote:
On Thu, 24 Jan 2019 at 15:28, Adrian Klaver wrote:
On 1/24/19 7:21 AM, Geoff Winkless wrote:
How could you even write a query like the one Thomas posted? It
doesn't even look remotely sensible.
delete from delete_test where 1::boolean;
*chuckle*
On Thu, 24 Jan 2019 at 15:32, Geoff Winkless wrote:
> DELETE FROM WHERE ;
>
> What would you be thinking that that ought to do?
To be fair, I suppose that accidentally missing out a test but
including an integer field
DELETE FROM WHERE ;
could do this. Not something I've ever done, but at lea
On Thu, 24 Jan 2019 at 15:28, Adrian Klaver wrote:
> On 1/24/19 7:21 AM, Geoff Winkless wrote:
> > How could you even write a query like the one Thomas posted? It
> > doesn't even look remotely sensible.
> delete from delete_test where 1::boolean;
*chuckle*
You misunderstand me.
I mean, how ca
On 1/24/19 7:21 AM, Geoff Winkless wrote:
On Thu, 24 Jan 2019 at 15:11, Tom Lane wrote:
People don't generally post to the lists after a type-mismatch error
catches a typo for them. So it's pretty hard to tell about "how
many" developers would find one behavior more useful than the other.
It i
On Thu, 24 Jan 2019 at 15:11, Tom Lane wrote:
> People don't generally post to the lists after a type-mismatch error
> catches a typo for them. So it's pretty hard to tell about "how
> many" developers would find one behavior more useful than the other.
> It is safe to say, though, that the same
On 1/24/19 3:04 AM, Alexandre GRAIL wrote:
Hello the list,
Maybe this question has been debated before (I didn't find anything
helpful) but :
Why the default is to throw an error when casting Integer to Boolean in
assignment, and accepting it everywhere else ?
The overall reason:
Geoff Winkless writes:
> On Thu, 24 Jan 2019 at 14:28, David G. Johnston
> wrote:
>> To assist developers in avoiding the writing of buggy queries.
> Amazing how many of these developers find this a hindrance. If only
> they could see how helpful we're being to them.
People don't generally post
On 1/24/19 9:05 AM, Geoff Winkless wrote:
On Thu, 24 Jan 2019 at 14:28, David G. Johnston
wrote:
To assist developers in avoiding the writing of buggy queries.
Amazing how many of these developers find this a hindrance. If only
they could see how helpful we're being to them.
It's the C vs. A
On Thu, 24 Jan 2019 at 14:28, David G. Johnston
wrote:
> To assist developers in avoiding the writing of buggy queries.
Amazing how many of these developers find this a hindrance. If only
they could see how helpful we're being to them.
Geoff
On Thu, Jan 24, 2019 at 4:04 AM Alexandre GRAIL
wrote:
> But you *cannot* use 1 or 0 as valid input for boolean type when
> inserting or updating :
>
> test=# CREATE TABLE test1 (a boolean);
> CREATE TABLE
> test=# INSERT INTO test1 VALUES (1);
> ERROR: column "a" is of type boolean but expressio
On 1/24/19 5:04 AM, Alexandre GRAIL wrote:
Hello the list,
Maybe this question has been debated before (I didn't find anything
helpful) but :
Why the default is to throw an error when casting Integer to Boolean in
assignment, and accepting it everywhere else ?
So you can
On Thu, 24 Jan 2019 at 12:17, Thomas Kellerer wrote:
> Geoff Winkless schrieb am 24.01.2019 um 12:45:
> > My own opinion is that non-0 should implicitly cast as true and 0
> > should cast as false.
>
> I strongly disagree - that would mimic MySQL's idiosyncrasies and would make
> such a query val
Geoff Winkless schrieb am 24.01.2019 um 12:45:
> The reason for that at least is that '1' and '0' are valid boolean values.
>
> https://www.postgresql.org/docs/9.5/datatype-boolean.html
>
> There's additional text describing why casts are chosen to be defined
> as implicit or not here
>
> https:
On Thu, 24 Jan 2019 at 11:04, Alexandre GRAIL
wrote:
>
> And added to this weirdness is the fact that '1' or '0' (with quote) is OK.
>
The reason for that at least is that '1' and '0' are valid boolean values.
https://www.postgresql.org/docs/9.5/datatype-boolean.html
There's additional text desc
Hello the list,
Maybe this question has been debated before (I didn't find anything
helpful) but :
Why the default is to throw an error when casting Integer to Boolean in
assignment, and accepting it everywhere else ?
So you can type :
postgres=# select 1::boolean;
bool
--
t
(
21 matches
Mail list logo
