Hello,
I am using PostgreSQL 8.2.4 with the 8.02.03.00 ODBC driver (unicode
build), windows environment.
The program uses SQLBulkOperations to obtain from postgres new unique
identifiers for a table before I insert the data that goes in that
table. The program works and runs without error when t
The following bug has been logged online:
Bug reference: 3417
Logged by: David Boesch
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: Linux Redhat Linux linux2 2.4.20-8 #1 Thu Mar 13
17:54:28 EST 2003 i686 i686 i386 GNU/Linux
Description:F
"David Boesch" <[EMAIL PROTECTED]> writes:
> I add data to reference
>
> select * from reference shows as
>
> id | name | description
> ++
> 11 | rd | road
> 12 | st | street
> 13 | way
"Matt" <[EMAIL PROTECTED]> writes:
> Description:plperl spi_exec_prepared variable undef value confusion
[ pokes at it ... ] Some of the places in plperl.c that are checking for
undef values use code like
if (SvOK(val) && SvTYPE(val) != SVt_NULL)
and some just test the SvTYPE pa
I wrote:
> [ pokes at it ... ] Some of the places in plperl.c that are checking for
> undef values use code like
> if (SvOK(val) && SvTYPE(val) != SVt_NULL)
> and some just test the SvTYPE part. It looks to me like the SvOK test
> is essential --- in fact I'm not sure the SvTYPE test is e
Greetings,
At http://www.postgresql.org/docs/8.2/static/sql-set-role.html, we
claim that 'SESSION and LOCAL modifiers act the same as for the
regular SET command', but I don't think that's actually right...
networx=> set role postgres;
SET
networx*=# show role;
role
--
postgr
Tom Lane wrote:
"Matt" <[EMAIL PROTECTED]> writes:
Description:plperl spi_exec_prepared variable undef value confusion
[ pokes at it ... ] Some of the places in plperl.c that are checking for
undef values use code like
if (SvOK(val) && SvTYPE(val) != SVt_NULL)
and
Stephen Frost <[EMAIL PROTECTED]> writes:
> At http://www.postgresql.org/docs/8.2/static/sql-set-role.html, we
> claim that 'SESSION and LOCAL modifiers act the same as for the
> regular SET command', but I don't think that's actually right...
I cannot duplicate the behavior you show, in eit
Hi,
FATAL: could not open lock file "/tmp/.s.PGSQL.5432.lock": Permission
denied
I got that error today.
My case:
I installed psql using user A, then I uninstalled it.
I installed psql using user B and I got that error.
Reason: The lock file in /tmp was owned by user A
Solution:
su and rm the l
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > At http://www.postgresql.org/docs/8.2/static/sql-set-role.html, we
> > claim that 'SESSION and LOCAL modifiers act the same as for the
> > regular SET command', but I don't think that's actually right...
>
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
>> I cannot duplicate the behavior you show, in either HEAD or 8.2.
> Wow. Okay, this is more interesting. It has some interaction with:
> \set ON_ERROR_ROLLBACK 'on'
> in my .psqlrc. If I remove that, then it wor
Tom Lane wrote:
> and the postmaster log has
>
> 2007-06-28 22:02:14.418 EDT 2870 LOG: statement: begin;
> 2007-06-28 22:02:26.044 EDT 2870 LOG: statement: SAVEPOINT
> pg_psql_temporary_savepoint
> 2007-06-28 22:02:26.045 EDT 2870 LOG: statement: set local role tgl;
> 2007-06-28 22:02:26.047
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Ah. log_statement = all tells the tale:
[...]
> 2007-06-28 22:02:14.418 EDT 2870 LOG: statement: begin;
> 2007-06-28 22:02:26.044 EDT 2870 LOG: statement: SAVEPOINT
> pg_psql_temporary_savepoint
> 2007-06-28 22:02:26.045 EDT 2870 LOG: statement: set loca
* Alvaro Herrera ([EMAIL PROTECTED]) wrote:
> Tom Lane wrote:
> > 2007-06-28 22:02:14.418 EDT 2870 LOG: statement: begin;
> > 2007-06-28 22:02:26.044 EDT 2870 LOG: statement: SAVEPOINT
> > pg_psql_temporary_savepoint
> > 2007-06-28 22:02:26.045 EDT 2870 LOG: statement: set local role tgl;
> > 2
Stephen Frost <[EMAIL PROTECTED]> writes:
>> So actually, ON_ERROR_ROLLBACK breaks *any* use of SET LOCAL, not just
>> ROLE. Not sure that this is fixable :-(
> That's not the behavior which is intended though, is it? SET LOCAL
> should be for an entire transaction, not for subtransactions/savep
15 matches
Mail list logo