On 10/12/2009 5:12 AM, Daniel Nagy wrote:
The following bug has been logged online:
Bug reference: 5238
Logged by: Daniel Nagy
Email address: nagy.dan...@telekom.hu
PostgreSQL version: 8.4.1
Operating system: Debian Lenny 5.0.3 x86_64. Kernel: 2.6.31.6-grsec
Description:
"Recursive complex query" writes:
> and the server report me the error: "ERROR: write failed"
Maybe you ran out of disk space? Are you sure the recursion terminates
at all, or does so before generating an enormous number of rows?
regards, tom lane
--
Sent via pgsql-bu
The following bug has been logged online:
Bug reference: 5239
Logged by: Recursive complex query
Email address: gusta1...@gmail.com
PostgreSQL version: 8.4
Operating system: Windows XP SP 2
Description:Recursive complex query
Details:
I try to run following query:
On Thu, Dec 10, 2009 at 12:32 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Dec 10, 2009 at 11:54 AM, Tom Lane wrote:
>>> The problem with USING is that it is not merely a join condition but
>>> affects the set of columns emitted by the join. It can't be converted
>>> to a simple ON with
On Thu, Dec 10, 2009 at 1:02 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Thu, Dec 10, 2009 at 11:57 AM, Tom Lane wrote:
>
>> > Hmm. Cute, but I wonder why we shouldn't just be throwing an error.
>> > As I said last night, the only thing I see wrong with the current
>> > behavior is t
Robert Haas escribió:
> On Thu, Dec 10, 2009 at 11:57 AM, Tom Lane wrote:
> > Hmm. Cute, but I wonder why we shouldn't just be throwing an error.
> > As I said last night, the only thing I see wrong with the current
> > behavior is that the error message isn't phrased in a way that makes
> > it
Robert Haas writes:
> On Thu, Dec 10, 2009 at 11:54 AM, Tom Lane wrote:
>> The problem with USING is that it is not merely a join condition but
>> affects the set of columns emitted by the join. It can't be converted
>> to a simple ON without changing the semantics, and I don't believe we
>> sho
On Thu, Dec 10, 2009 at 11:54 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Dec 10, 2009 at 1:46 AM, Tom Lane wrote:
>>> My reading of the spec is that USING (and therefore NATURAL) is defined
>>> to join identically named columns. Therefore, renaming one of the input
>>> columns as the
On Thu, Dec 10, 2009 at 11:57 AM, Tom Lane wrote:
> Andrew Gierth writes:
>> There's another possible solution (albeit a somewhat nontrivial one)
>> which came up when a bunch of us were talking about this one on IRC;
>> which is to handle the problem in the view deparse: if a column used
>> in a
Andrew Gierth writes:
> There's another possible solution (albeit a somewhat nontrivial one)
> which came up when a bunch of us were talking about this one on IRC;
> which is to handle the problem in the view deparse: if a column used
> in a USING clause has been renamed, add an alias to the query
Robert Haas writes:
> On Thu, Dec 10, 2009 at 1:46 AM, Tom Lane wrote:
>> My reading of the spec is that USING (and therefore NATURAL) is defined
>> to join identically named columns. Therefore, renaming one of the input
>> columns as the OP did *should* indeed *must* break the view. The proble
On Thu, Dec 10, 2009 at 10:48 AM, Andrew Gierth
wrote:
>> "Robert" == Robert Haas writes:
>
> > On Thu, Dec 10, 2009 at 1:46 AM, Tom Lane wrote:
> >>
> >> My reading of the spec is that USING (and therefore NATURAL) is
> >> defined to join identically named columns. Therefore, renaming
> "Robert" == Robert Haas writes:
> On Thu, Dec 10, 2009 at 1:46 AM, Tom Lane wrote:
>>
>> My reading of the spec is that USING (and therefore NATURAL) is
>> defined to join identically named columns. Therefore, renaming
>> one of the input columns as the OP did *should* indeed *must*
On Thu, Dec 10, 2009 at 1:46 AM, Tom Lane wrote:
> Robert Haas writes:
>> I'm not an expert on this area of the code, but can we just ignore
>> isNatural and usingClause when deparsing?
>
> No. These properties are *not* ignorable because doing so changes the
> set of returned columns --- you sh
"Daniel Nagy" writes:
> The binaries are not stripped, how can I help finding the cause?
Get a stack trace from the core dump using gdb.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.po
The following bug has been logged online:
Bug reference: 5238
Logged by: Daniel Nagy
Email address: nagy.dan...@telekom.hu
PostgreSQL version: 8.4.1
Operating system: Debian Lenny 5.0.3 x86_64. Kernel: 2.6.31.6-grsec
Description:frequent signal 11 segfaults
Details:
Mike Landis wrote:
> I am trying to experiment with the libpqxx API and postgresql 8.4.1 on a
> 32-bit
> Vista machine. Libpqxx wants release and debug libraries for libpq
> available.
Why libpqxx want the debug library?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
17 matches
Mail list logo
