Jan Wieck <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>>> 4. Use the parser's coerce_to_boolean procedure, so that nonbooleans
>>> will be accepted in exactly the same cases where they'd be accepted
>>> in a boolean-requiring SQL construct (such as CASE). (By default,
>>> none are, so this isn't
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Where are we on this --- we all decided on #4. Does this just require
> an announcment in the release notes.
I haven't done anything about it --- been busy with other stuff, and I
wasn't sure we'd agreed to change it for 7.4 anyway. I'm willing to
make
Where are we on this --- we all decided on #4. Does this just require
an announcment in the release notes.
(I need to complete the release notes soon.)
---
Tom Lane wrote:
> Following up this gripe
> http://archives.postgr
Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
ERROR is the cleanest way, but I'd vote for conversion to boolean to
keep the damage within reason.
Which style of conversion did you like? These were the choices:
3. Try to convert nonbooleans to boolean using plpgsql's usual method
for cr
Tom Lane wrote:
4. Use the parser's coerce_to_boolean procedure, so that nonbooleans
will be accepted in exactly the same cases where they'd be accepted
in a boolean-requiring SQL construct (such as CASE). (By default,
none are, so this isn't really different from #2. But people could
create cas
Jan Wieck <[EMAIL PROTECTED]> writes:
> ERROR is the cleanest way, but I'd vote for conversion to boolean to
> keep the damage within reason.
Which style of conversion did you like? These were the choices:
>> 3. Try to convert nonbooleans to boolean using plpgsql's usual method
>> for cross-typ
Tom Lane wrote:
Following up this gripe
http://archives.postgresql.org/pgsql-sql/2003-09/msg00044.php
I've realized that plpgsql just assumes that the test expression
of an IF, WHILE, or EXIT statement is a boolean expression. It
doesn't take any measures to ensure this is the case or convert
t
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
What's the practice in deprecating other "features"?
We generally don't ;-). Certainly 7.4 contains bigger incompatible
changes than this one, and so have most of our prior releases.
I thought I had seen discussions along the l
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> How would we "deprecate" it exactly? Throw a NOTICE?
>>
> Release notes, I guess. A NOTICE would be fine as long as it didn't
> result in a flood of them. If that happened once at parse time that
> should be fine, I think.
It woul
Tom Lane wrote:
Doug McNaught <[EMAIL PROTECTED]> writes:
I agree with another poster that deprecation in 7.4 and removal in
7.5 might make sense.
How would we "deprecate" it exactly? Throw a NOTICE?
Release notes, I guess. A NOTICE would be fine as long as it didn't
result in a floo
Tom Lane wrote:
Doug McNaught <[EMAIL PROTECTED]> writes:
I agree with another poster that deprecation in 7.4 and removal in
7.5 might make sense.
How would we "deprecate" it exactly? Throw a NOTICE?
Good question. A NOTICE just might be ignored, breaking everything
"surprisingly" in 7.
Tom Lane <[EMAIL PROTECTED]> writes:
> Doug McNaught <[EMAIL PROTECTED]> writes:
> > I agree with another poster that deprecation in 7.4 and removal in
> > 7.5 might make sense.
>
> How would we "deprecate" it exactly? Throw a NOTICE?
I was thinking of just a mention in the release notes that w
Doug McNaught <[EMAIL PROTECTED]> writes:
> I agree with another poster that deprecation in 7.4 and removal in
> 7.5 might make sense.
How would we "deprecate" it exactly? Throw a NOTICE?
regards, tom lane
---(end of broadcast)
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>
> >
> >2. Throw an error if the expression doesn't return boolean.
> >
> I'd opt for 2.
> It's quite common that newer compilers will detect more bogus coding
> than older ones. There might be existing functions that break from
> this
Tom Lane wrote:
Here are some possible responses, roughly in order of difficulty
to implement:
1. Leave well enough alone (and perhaps document the behavior).
2. Throw an error if the expression doesn't return boolean.
I'd opt for 2.
It's quite common that newer compilers will detect more bogus
Tom Lane wrote:
Following up this gripe
http://archives.postgresql.org/pgsql-sql/2003-09/msg00044.php
I've realized that plpgsql just assumes that the test expression
of an IF, WHILE, or EXIT statement is a boolean expression. It
doesn't take any measures to ensure this is the case or convert
the
Following up this gripe
http://archives.postgresql.org/pgsql-sql/2003-09/msg00044.php
I've realized that plpgsql just assumes that the test expression
of an IF, WHILE, or EXIT statement is a boolean expression. It
doesn't take any measures to ensure this is the case or convert
the value if it's no
17 matches
Mail list logo
