From: | Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #5783: plpythonu bool behavior change |
Date: | 2010-12-05 19:15:34 |
Message-ID: | 201012051115.34553.adrian.klaver@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Sunday 05 December 2010 9:10:06 am Peter Eisentraut wrote:
> On sön, 2010-12-05 at 00:25 +0000, Adrian Klaver wrote:
> > Seems there was a change in behavior for plpythonu with regards to
> > boolean fields from 8.4 to 9.0. Previously, setting a field inside a
> > plpythonu function to "f" would work, now that returns a 't' in the
> > database field. To get the 'f' to appear I have to specify False
> > inside the function.
>
> That change was intentional.
Alright my mistake, I finally went past the release notes and read the new docs
for plpythonu. I see the changes. I do not agree with them, but I should have
paid more attention in the dev process. The value is being returned to the
database and should play by the database rules or at least be flagged. I will
make the necessary changes on my end.
Thanks,
--
Adrian Klaver
adrian(dot)klaver(at)gmail(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2010-12-06 12:47:02 | Re: [BUGS] BUG #5662: Incomplete view |
Previous Message | Martin Atukunda | 2010-12-05 19:06:21 | Re: BUG #5784: CREATE INDEX USING GIN complains about array containing null values yet none exist |