Hi Tom,
Well I thought I was running version "8.4.*" but it turned out to be "8.2.14"
when I did a show server_version in pgAdminIII. So, is this a known issue?
Well I won't possibly be able to upgrade the version as its bundled with the
DB. :-(
Cordially,
Biju George
UST Global | Trivandrum
But 9.0.7 compiles fine. 8.4.11 too.
On Thu, Apr 12, 2012 at 03:55:01PM -0400, Tom Lane wrote:
> m...@akamit.com writes:
> > Operating system: AIX 7.1.0
> > While compiling from source the following error stops the compilation
> > process
>
> > ld: 0711-317 ERROR: Undefined symbol: .mbstowcs_l
Andrey Mitroshin writes:
> But 9.0.7 compiles fine. 8.4.11 too.
That's fairly irrelevant, since the code that wants to use wcstombs_l()
and mbstowcs_l() is new in 9.1 (it's part of COLLATE-clause support).
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bug
On Thu, Apr 5, 2012 at 2:39 AM, Hitoshi Harada wrote:
> On Wed, Apr 4, 2012 at 8:00 AM, Tom Lane wrote:
>> umi.tan...@gmail.com writes:
>>> http://www.postgresql.org/docs/9.1/static/spi-spi-execute.html
>>
>>> ===
>>> SPI_execute("INSERT INTO foo SELECT * FROM bar", false, 5);
>>> will allow at m
The following bug has been logged on the website:
Bug reference: 6587
Logged by: Mike Boldi
Email address: mbo...@prospectiv.com
PostgreSQL version: 9.0.3
Operating system: Linux/Redhat
Description:
in the manual it says
If a limit count is given, no more than that ma
On Fri, Apr 13, 2012 at 8:40 PM, wrote:
> I am doing a large query so I limit the query to 550 but I get 88 rows
> returned. I increase this to 900 and get 136 rows returned ..
> explain Plan ...
Please send the query with and without the LIMIT.
It might also help to send more such as t
On 04/13/12 12:40 PM, mbo...@prospectiv.com wrote:
Aggregate (cost=1689951.65..1689951.66 rows=1 width=0)
-> Hash Join (cost=644.62..1687656.17 rows=918194 width=0)
Hash Cond: (a.email_a = o.email)
-> Subquery Scan on a (cost=0.00..1654854.18 rows=9149 width=64)
>
> Yeah. I think it would be a good idea for UPDATE and DELETE to expose
> a LIMIT option, but I can't really see the virtue in making that
> functionality available only through SPI.
>
I don't agree - LIMIT after UPDATE or DELETE has no sense. Clean
solution should be based on using updateable
On Fri, Apr 13, 2012 at 10:43 PM, Pavel Stehule wrote:
>> Yeah. I think it would be a good idea for UPDATE and DELETE to expose
>> a LIMIT option, but I can't really see the virtue in making that
>> functionality available only through SPI.
>
> I don't agree - LIMIT after UPDATE or DELETE has no
