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 dis
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
"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 sem
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-STATE
"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.
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 displ
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
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 mys
> "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.o
> "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 i
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 buil
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
"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-t
"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
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 calculat
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(
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
17 matches
Mail list logo
