Tom Lane wrote:
> plpgsql does not consider standard_conforming_strings --- it still uses
> backslash escaping in its function bodies regardless. Since the
> language itself is not standardized, I see no particular reason that
> standard_conforming_strings should govern it.
I think plpgsql should
"Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> the mean time here is a new backtrace I just got (lord knows how... it
> seems to be as soon as I stop trying to make it crash and look away,
> thats when it does).
Not sure that you are clear on what's happening here, but the train of
events is someth
On Wed, Mar 12, 2008 at 12:19 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Now personally, I am much more interested in *reproducing* the problem
> than merely dodging it. I can understand if you just need a workaround
> yesterday, but please see if you can get a reproducible test case ...
>
>
"Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> I can turn that off and only use DBI->prepare() as a test. Or heck
> just cut DBI->prepare() out and just quote everything and send them
> through using DBI->do() instead. That is if you think that could be
> the culprit.
The path of control that's d
Oops we actually use DBI->prepare_cached() not DBI->prepare() which to
my understanding should be roughly equivalent to (because of
Apache::DBI):
prepare query ;
begin;
execute query;
commit;
(next page load)
begin;
execute query;
commit;
I can turn that off and only use DBI->prepare() as a t
FYI right now Im trying:
Author: tgl
Date: Sat Feb 2 22:26:17 2008 +
Fix WaitOnLock() to ensure that the process's "waiting" flag is reset after
erroring out of a wait. We can use a PG_TRY block for this, but
add a comment
explaining why it'd be a bad idea to use it for any ot
On Tue, Mar 11, 2008 at 10:59 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> > Problem: Apparently random segfaults apparently query agnostic, seem
> > to be more frequent when a pg_dump is running
>
> Hmm, seems from the backtrace that we're trying to
"Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> Problem: Apparently random segfaults apparently query agnostic, seem
> to be more frequent when a pg_dump is running
Hmm, seems from the backtrace that we're trying to do a replan with an
invalid ActiveSnapshot. What sequence of operations is the co
(Sorry if duplicates show up this is the third time ive posted this in
the past 10 hours, Im assuming it got dropped because of the
attachments)
Problem: Apparently random segfaults apparently query agnostic, seem
to be more frequent when a pg_dump is running
The most frequent query it segfault
"Jonathan Guthrie" <[EMAIL PROTECTED]> writes:
> I have set the standard_conforming_strings to "on" in my settings ...
> However, when I attempt to define this function:
> create function foo (out r refcursor) as $bar$
> begin
> open r for
>select * from user_data
>where name_first like n
The following bug has been logged online:
Bug reference: 4027
Logged by: Jonathan Guthrie
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.0
Operating system: Debian Gnu/Linux "unstable" 2.6.24
Description:backslash escaping not disabled in plpgsql
Details:
"Yogesh" <[EMAIL PROTECTED]> writes:
> If I query database from my DB server which is on the same linux box, it
> diplays the wrong dates.Like actual date in my table is say 17-MAR-08
> 11.59.00 PM, then it displays 2008-03-18 00:59:00.
> and If I query the DB using a standalone script then it give
The following bug has been logged online:
Bug reference: 4026
Logged by: Yogesh
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.3.2
Operating system: linux
Description:Displaying Wrong dates
Details:
If I query database from my DB server which is on the same
Using PostgreSQL 8.2.3, on linux (FC3):
test=> select lseg'((0,0),(1,0))' ?# lseg'((0,0),(1,0))';
-[ RECORD 1 ]
?column? | f
while
avail=> select lseg'((0,0),(1,0))' ?# lseg'((0,0),(1,1))';
-[ RECORD 1 ]
?column? | t
Looking over the geometric operations source it appears that the
intersect o
The following bug has been logged online:
Bug reference: 4025
Logged by: James
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.0.1
Operating system: winXP
Description:wsock32.dll not found
Details:
when installation reach initdb stage, it shows can not init
15 matches
Mail list logo
