[BUGS] BUG #4514: Pi division error
The following bug has been logged online: Bug reference: 4514 Logged by: Traci Sumpter Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.3 Operating system: Linux Description:Pi division error Details: I am trying to do some calculations within Postgresql and am not getting the expected result. the first set proves that the pi works as expected with multiplication. Equation 180*pi VB 565.486677646163 Calculator 565.486677646163 PostgreSQL 565.486677646163 Php565.48667764616 However if I extend this equation postgres definately fails this test. Equation (315-0)/180*pi VB 5.49778714378213 Calculator 5.497787144 PostgreSQL 3.14159265358979 Php5.4977871437821 Help -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4514: Pi division error
Traci Sumpter escribió: The following bug has been logged online: Bug reference: 4514 Logged by: Traci Sumpter Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.3 Operating system: Linux Description:Pi division error Details: I am trying to do some calculations within Postgresql and am not getting the expected result. the first set proves that the pi works as expected with multiplication. Equation 180*pi VB 565.486677646163 Calculator 565.486677646163 PostgreSQL 565.486677646163 Php565.48667764616 However if I extend this equation postgres definately fails this test. Equation (315-0)/180*pi VB 5.49778714378213 Calculator 5.497787144 PostgreSQL 3.14159265358979 Php5.4977871437821 Help hola el problema que entero/entero = entero lo que debes hacer es (315.0-0)/180*pi saludos Fernando -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4515: UPDATE strange behavior
"xtron" <[EMAIL PROTECTED]> writes: > this is NOT work: > update a1 set a1.value = a2.value from a2 where a1.id = a2.id; This syntax is disallowed by the SQL standard: a SET target is just the name of the column. If we tried to interpret it as you suggest then we'd be incompatible for composite-type columns. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4514: Pi division error
On 2008-11-06 07:56, Traci Sumpter wrote: > Equation (315-0)/180*pi > PostgreSQL 3.14159265358979 You equation in SQL looks like this: => select (315-0)/180*pi from (select 3.14159265358979 as pi) as a; Which is an equivalent of: => select (315/180)*pi from (select 3.14159265358979 as pi) as a; And because 315 and 180 are integers so (315/180) is rounded down to integer (1): => select 1*pi from (select 3.14159265358979 as pi) as a; I think you need: => select (315.0-0)/180*pi from (select 3.14159265358979 as pi) as a; 5.497787143782132500 Any strongly typed language will do this, for example in python: $ python -c 'pi=3.14159265358979; print (315-0)/180*pi;' 3.14159265359 $ python -c 'pi=3.14159265358979; print (315.0-0)/180*pi;' 5.49778714378 Regards Tometzky -- ...although Eating Honey was a very good thing to do, there was a moment just before you began to eat it which was better than when you were... Winnie the Pooh -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
"Alex Hunsaker" <[EMAIL PROTECTED]> writes: > On Wed, Nov 5, 2008 at 18:03, Andrew Gierth <[EMAIL PROTECTED]> wrote: >> Then explain why the problem goes away when you build perl with >> threading turned off. > Hrm yep i built one without threads problem disappears... Guess Ive > just been out to lunch :) So we have an example of a pure-Perl script, with no visible threading dependency, that behaves differently with and without threads. Who's filing the bug report? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4515: UPDATE strange behavior
The following bug has been logged online: Bug reference: 4515 Logged by: xtron Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.5 Operating system: Debian GNU/Linux Description:UPDATE strange behavior Details: IMHO this is strange behavior: create table a1(id int, value int); create table a2(id int, value int); this is work: update a1 set value = a2.value from a2 where a1.id = a2.id; this is NOT work: update a1 set a1.value = a2.value from a2 where a1.id = a2.id; -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
On Thu, Nov 6, 2008 at 06:41, Tom Lane <[EMAIL PROTECTED]> wrote: > "Alex Hunsaker" <[EMAIL PROTECTED]> writes: >> On Wed, Nov 5, 2008 at 18:03, Andrew Gierth <[EMAIL PROTECTED]> wrote: >>> Then explain why the problem goes away when you build perl with >>> threading turned off. > >> Hrm yep i built one without threads problem disappears... Guess Ive >> just been out to lunch :) > > So we have an example of a pure-Perl script, with no visible threading > dependency, that behaves differently with and without threads. Who's > filing the bug report? I submitted http://rt.perl.org/rt3/Public/Bug/Display.html?id=60374 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
> "Alex" == Alex Hunsaker <[EMAIL PROTECTED]> writes:
>> Then explain why the problem goes away when you build perl with
>> threading turned off.
Alex> Hrm yep i built one without threads problem disappears... Guess
Alex> Ive just been out to lunch :)
If it helps any, I've tracked down in the perl guts exactly why this
happens:
cop.h:
struct cop {
BASEOP
char * cop_label; /* label for this construct */
#ifdef USE_ITHREADS
char * cop_stashpv;/* package line was compiled in */
char * cop_file; /* file name the following line # is from */
#else
HV *cop_stash; /* package line was compiled in */
GV *cop_filegv; /* file the following line # is from */
#endif
U32 cop_seq;/* parse sequence number */
I32 cop_arybase;/* array base this line was compiled with */
line_t cop_line; /* line # of this command */
SV *cop_warnings; /* lexical warnings bitmask */
SV *cop_io; /* lexical IO defaults */
};
A COP in perl is a control operation, basically a compiled statement,
and the pointer to the current COP is used to determine all the
lexical state, including the current package. pp_sort uses
CopSTASH(PL_curcop) to get the package stash (symbol table) in order
to locate the $a and $b variables in it.
Notice, though, that without ithreads, the COP points directly to the
stash, but with ithreads, it points instead to the _name_ of the stash
(e.g. "main"). The problem arises because with Safe in use, the
package created by Safe to use as a container _thinks_ that its name
is "main" even though it's not, so the COPs compiled inside it point
to the name "main" rather than to the real name of the container.
So with ithreads enabled, pp_sort looks up the package stash by name,
gets the "main" package rather than the safe container, and creates
$main::a and $main::b to store the comparison values in. But the
compiled comparison block has its own references to the variables
which refers to the correct stash, so it all goes Horribly Wrong at
that point.
So there are three factors involved:
1) the change in layout of COP with ithreads enabled
2) the fact that Safe changes the internally-seen name of a package
3) any operation that relies on CopSTASH(PL_curcop) (I can only find a
few: sort, reset, and bless) will then behave incorrectly
However, I have no idea why Perl has this difference between threaded
and non-threaded code.
--
Andrew.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
On Thu, Nov 6, 2008 at 09:03, Andrew Gierth <[EMAIL PROTECTED]> wrote: >> "Alex" == Alex Hunsaker <[EMAIL PROTECTED]> writes: > > Alex> I submitted http://rt.perl.org/rt3/Public/Bug/Display.html?id=60374 > > Feel free to add my explanation to that (I couldn't see an obvious way > to do it myself) Added (I think), FYI looks like you should just be able to send a mail to [EMAIL PROTECTED] with [perl #60374] in the subject. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
On Thu, Nov 6, 2008 at 09:00, Andrew Gierth <[EMAIL PROTECTED]> wrote: > If it helps any, I've tracked down in the perl guts exactly why this > happens: Cool > Notice, though, that without ithreads, the COP points directly to the > stash, but with ithreads, it points instead to the _name_ of the stash > (e.g. "main"). The problem arises because with Safe in use, the > package created by Safe to use as a container _thinks_ that its name > is "main" even though it's not, so the COPs compiled inside it point > to the name "main" rather than to the real name of the container. Ok so I kind of analyzed it right, just missed the threading issue. (namely that its referencing a different main when we execute it outside of "Safe") FYI the commit that changd it is http://perl5.git.perl.org/?p=perl.git;a=commitdiff;h=18537ab8315c273284bfe269f1678095c399c053;hp=89cb812aee601e19db5eb36b2c6e74980a348661 It been this way since 1999 with the descriptive commit message 'avoid stash pointers in optree under USE_ITHREADS' -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
> "Alex" == Alex Hunsaker <[EMAIL PROTECTED]> writes: Alex> I submitted http://rt.perl.org/rt3/Public/Bug/Display.html?id=60374 Feel free to add my explanation to that (I couldn't see an obvious way to do it myself) -- Andrew. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4516: FOUND variable does not work after RETURN QUERY
The following bug has been logged online:
Bug reference: 4516
Logged by: Michal szymanski
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3
Operating system: Windows
Description:FOUND variable does not work after RETURN QUERY
Details:
This short program display two rows instead one. If I use RETURN NEXT it
works.
CREATE TABLE test_table (
value VARCHAR
);
INSERT INTO test_table VALUES ('a');
INSERT INTO test_table VALUES ('b');
CREATE OR REPLACE FUNCTION test()
RETURNS SETOF test_table AS
$BODY$
DECLARE
BEGIN
RETURN QUERY
SELECT * FROM test_table WHERE value='a';
IF NOT FOUND THEN
RETURN QUERY
SELECT * FROM test_table WHERE value='b';
END IF;
RETURN;
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE;
select * from test()
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4516: FOUND variable does not work after RETURN QUERY
"Michal szymanski" <[EMAIL PROTECTED]> writes: > Description:FOUND variable does not work after RETURN QUERY The list of statements that set FOUND is here: http://www.postgresql.org/docs/8.3/static/plpgsql-statements.html#PLPGSQL-STATEMENTS-DIAGNOSTICS RETURN isn't one of them. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4516: FOUND variable does not work after RETURN QUERY
Hello 2008/11/6 Tom Lane <[EMAIL PROTECTED]>: > "Michal szymanski" <[EMAIL PROTECTED]> writes: >> Description:FOUND variable does not work after RETURN QUERY > > The list of statements that set FOUND is here: > http://www.postgresql.org/docs/8.3/static/plpgsql-statements.html#PLPGSQL-STATEMENTS-DIAGNOSTICS > > RETURN isn't one of them. > >regards, tom lane > It should be enhanced - my initial proposal of return query expected so return query is last statement, that isn't now. So we could add this check there. regards Pavel Stehule > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4516: FOUND variable does not work after RETURN QUERY
"Pavel Stehule" <[EMAIL PROTECTED]> writes: > 2008/11/6 Tom Lane <[EMAIL PROTECTED]>: >> RETURN isn't one of them. > It should be enhanced - my initial proposal of return query expected > so return query is last statement, that isn't now. So we could add > this check there. Well, changing the semantics of an already-released statement carries a risk of breaking existing apps that aren't expecting it to change FOUND. So I'd want to see a pretty strong case why this is important --- not just that it didn't meet someone's didn't-read-the-manual expectation. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4516: FOUND variable does not work after RETURN QUERY
2008/11/6 Tom Lane <[EMAIL PROTECTED]>: > "Pavel Stehule" <[EMAIL PROTECTED]> writes: >> 2008/11/6 Tom Lane <[EMAIL PROTECTED]>: >>> RETURN isn't one of them. > >> It should be enhanced - my initial proposal of return query expected >> so return query is last statement, that isn't now. So we could add >> this check there. > > Well, changing the semantics of an already-released statement carries a > risk of breaking existing apps that aren't expecting it to change FOUND. > So I'd want to see a pretty strong case why this is important --- not > just that it didn't meet someone's didn't-read-the-manual expectation. > It's should do some problems, but I belive much less than change of casting or tsearch2 integration. And actually it's not ortogonal. Every not dynamic statement change FOUND variable. regards Pavel Stehule >regards, tom lane > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4509: array_cat's null behaviour is inconsistent
Kev <[EMAIL PROTECTED]> writes:
>> I'm loath to change just this one thing though. If we're going to
>> monkey with it, I think we should start by having a thought-through
>> proposal about the behavior of all the array functions for corner
>> cases like null arrays and empty arrays (cf recent discussion about
>> zero-dimensional arrays).
> If those are the only corner cases, here's something to work with.
I don't think it's quite as easy as you think ...
> Looking at
> http://www.postgresql.org/docs/8.3/interactive/functions-array.html,
> I'd propose that every one of those operators and functions should
> return NULL::(normal-return-type) if any of their operands are NULL,
It is *certainly* not the case that array_append and array_prepend
should return NULL when their scalar argument is NULL --- that would
break a key component of the support for null elements in arrays.
As for the array argument, consider this plpgsql code:
declare arr int[];
r record;
begin
for r in select ... loop
arr := arr || r.intfield;
end loop;
Right now that will "do the right thing" because array_append treats
a null array input as though it were empty. Now we could decree that
this code is wrong and the user should have initialized arr to '{}' or
some such, but ISTM that that's basically breaking code to no purpose.
There isn't any real type-safety or other code quality benefit to be
gained from making this fail.
(After having thought about it a bit, I believe that the rationale for
having array_cat treat null arrays as it does was similar.)
> || (both array-array cases) return other array if one is empty (if
> left is empty, return right, elsif right is empty, return left)
We could do that, but note that || has two different behaviors depending
on whether the arrays have the same rank, and it throws an error if the
ranks are more than one apart. So doing the above amounts to saying
that an empty array can have any rank depending on context. Not sure
that I like that --- this gets back to the whole issue of exactly what
we define an empty array as meaning. (Note that array_cat does in fact
currently behave as you suggest. So changing it could break existing
code; but I'm thinking that there would be far fewer such cases than
for the append-a-scalar situation.)
> array_lower raise exception if array is empty (there are no dimensions
> to inquire about)
> array_upper raise exception if array is empty (there are no dimensions
> to inquire about)
Well, these beg the question: is an empty array zero-dimensional, or
is it a one-dimensional array of no elements, or perhaps both of those
as well as higher-dimensional cases where any axis has zero elements,
or ???
It's really all kind of messy ... we need to trade off simplicity of
definition, ease of use, backwards compatibility, and standards
compliance (though the standard has only 1-D arrays so it's of just
limited help here).
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
