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
Hm.
Andrey Mitroshin m...@akamit.com 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
On Thu, Apr 5, 2012 at 2:39 AM, Hitoshi Harada umi.tan...@gmail.com wrote:
On Wed, Apr 4, 2012 at 8:00 AM, Tom Lane t...@sss.pgh.pa.us 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,
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
On Fri, Apr 13, 2012 at 8:40 PM, mbo...@prospectiv.com 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
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 CTE.
On Fri, Apr 13, 2012 at 10:43 PM, Pavel Stehule pavel.steh...@gmail.com 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
