Hi,
I got the following message when I ran pg_dump with -Ft option on
Windows XP.
> pg_dump -V
pg_dump (PostgreSQL) 8.1.2
> pg_dump -Ft test > C:\backup\xxx.out
pg_dump: [tar archiver] could not generate temporary file name: Permission
denied
pg_dump calls tmpfile() in pg_backup_tar.c:tarOpen
Oooh. Based on emails I've received I should point out that phpPgAdmin
is a FREE, VOLUNTEER project! It's not a paid job offer!
Christopher Kings-Lynne wrote:
Hi,
The phpPgAdmin project has been pretty quiet for some time now. We have
decided to try to build up our developer base again by
Hi,
Im getting this error when I try to connect to a postgresql database
from a web application running on tomcat
the error is from the postgersql logs
ERROR: No parser with id 17555
The error below is from tomcat logs:
---
(executing StatementCallback): encountered
SQLException [ERR
Hi,
The phpPgAdmin project has been pretty quiet for some time now. We have
decided to try to build up our developer base again by recruiting some
new, interested, PHP developers.
The core team is still around to offer guidance, suggestions, releases,
etc. however no-one seems to have much
I spent some time today going through the stuff on the Coverity
website. I basically looked at every report outside of src/backend (due
to the ereport false-positives (elog is fixed)) and src/interfaces/ecpg
(due to the shear volume of probably bugs).
I've sorted them into:
FALSE - Not a bug, Cov
Attachment now attached. :-)
---
Bruce Momjian wrote:
>
> Interesting bug report. The problem is that sscanf(buf, "%d", &val)
> eats leading white space, but our functions were not handling that.
>
> I have applied the a
Interesting bug report. The problem is that sscanf(buf, "%d", &val)
eats leading white space, but our functions were not handling that.
I have applied the attached patch that fixes this:
test=> select to_timestamp(' 0300','mmdd hh24mi');
to_timestamp
Martijn van Oosterhout writes:
> I'm wondering who is responsible for ECPG since there appear to be a
> number questionable statements which may or may not be bugs. Do we have
> a resident expert?
Michael Meskes is The Man as far as ecpg goes ...
regards, tom lane
--
I'm wondering who is responsible for ECPG since there appear to be a
number questionable statements which may or may not be bugs. Do we have
a resident expert?
Examples:
src/interfaces/ecpg/ecpglib/execute.c line 871
To my untrained eye it looks like after the first time through the loop
it's go
Joshua D. Drake wrote:
> John DeSoi wrote:
> >Proposed item: Improve PL/PHP support, especially installation on
> >non-Linux platforms. PL/PHP does not currently work on OS X (not sure
> >about Windows, but I doubt it).
>
> It definitely does NOT work on Windows. MacOSX is just a matter of us
>
John DeSoi wrote:
Proposed item: Improve PL/PHP support, especially installation on
non-Linux platforms. PL/PHP does not currently work on OS X (not sure
about Windows, but I doubt it).
It definitely does NOT work on Windows. MacOSX is just a matter of us
having some time.
Alvaro indicated
On 4/19/06, John DeSoi <[EMAIL PROTECTED]> wrote:
> Alvaro indicated he would be willing to provide direction on this
> with testing support from me. He also said there are several other
> possible PL/PHP issues that would warrant a SoC project.
Cool... let's get 'em all listed here so we can move
Proposed item: Improve PL/PHP support, especially installation on non-
Linux platforms. PL/PHP does not currently work on OS X (not sure
about Windows, but I doubt it).
Alvaro indicated he would be willing to provide direction on this
with testing support from me. He also said there are seve
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> if define HAVE_INT64_TIMESTAMP
> result is: 4E66 E642 0030 C274
> if not define HAVE_INT64_TIMESTAMP
> {
> if define INT64_IS_BUSTED result is: 6972 2142 00DB
> if not define INT64_IS_BUSTED result is: 4221 7269 DB00
> }
I think you
On Wed, Apr 19, 2006 at 12:31:23PM +0300, Adrian Maier wrote:
> Hello hackers,
>
> I have included below a fragment of a discussion from the freepascal mailing
> list. Apparently, some folks expect to be able to start multiple transactions
> inside the *same* database connection. Since this is no
> I have included below a fragment of a discussion from the freepascal
mailing
> list. Apparently, some folks expect to be able to start multiple
transactions
[...]
> inside the *same* database connection.
>
> My feeling is that this is a false problem, caused by some
interbase/firebird
> or delp
Hello hackers,
I have included below a fragment of a discussion from the freepascal mailing
list. Apparently, some folks expect to be able to start multiple transactions
inside the *same* database connection. Since this is not possible in postgres,
they would be forced to start more connections f
> > (2) the killer function is PGSemaphoreReset(). There is no direct
> > function for this in Win32 either.
>
> If you can do PGSemaphoreTryLock, then Reset need only be a
> loop around it (cf. posix_sema.c). In current usage Reset
> doesn't have to be very efficient at all, because it's only
18 matches
Mail list logo