[COMMITTERS] pgsql: Only install a portal's ResourceOwner if it actually has one.

2013-06-13 Thread Tom Lane
Only install a portal's ResourceOwner if it actually has one. In most scenarios a portal without a ResourceOwner is dead and not subject to any further execution, but a portal for a cursor WITH HOLD remains in existence with no ResourceOwner after the creating transaction is over. In this situatio

[COMMITTERS] pgsql: Only install a portal's ResourceOwner if it actually has one.

2013-06-13 Thread Tom Lane
Only install a portal's ResourceOwner if it actually has one. In most scenarios a portal without a ResourceOwner is dead and not subject to any further execution, but a portal for a cursor WITH HOLD remains in existence with no ResourceOwner after the creating transaction is over. In this situatio

[COMMITTERS] pgsql: Only install a portal's ResourceOwner if it actually has one.

2013-06-13 Thread Tom Lane
Only install a portal's ResourceOwner if it actually has one. In most scenarios a portal without a ResourceOwner is dead and not subject to any further execution, but a portal for a cursor WITH HOLD remains in existence with no ResourceOwner after the creating transaction is over. In this situatio

[COMMITTERS] pgsql: Only install a portal's ResourceOwner if it actually has one.

2013-06-13 Thread Tom Lane
Only install a portal's ResourceOwner if it actually has one. In most scenarios a portal without a ResourceOwner is dead and not subject to any further execution, but a portal for a cursor WITH HOLD remains in existence with no ResourceOwner after the creating transaction is over. In this situatio

[COMMITTERS] pgsql: Only install a portal's ResourceOwner if it actually has one.

2013-06-13 Thread Tom Lane
Only install a portal's ResourceOwner if it actually has one. In most scenarios a portal without a ResourceOwner is dead and not subject to any further execution, but a portal for a cursor WITH HOLD remains in existence with no ResourceOwner after the creating transaction is over. In this situatio

[COMMITTERS] pgsql: PL/Python: Fix type mixup

2013-06-13 Thread Peter Eisentraut
PL/Python: Fix type mixup Memory was allocated based on the sizeof a type that was not the type of the pointer that the result was being assigned to. The types happen to be of the same size, but it's still wrong. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/fa2fc

[COMMITTERS] pgsql: Refactor checksumming code to make it easier to use externally.

2013-06-13 Thread Tom Lane
Refactor checksumming code to make it easier to use externally. pg_filedump and other external utility programs are likely to want to be able to check Postgres page checksums. To avoid messy duplication of code, move the checksumming functionality into an exported header file, much as we did awhi

[COMMITTERS] pgsql: Remove special-case treatment of LOG severity level in standalon

2013-06-13 Thread Tom Lane
Remove special-case treatment of LOG severity level in standalone mode. elog.c has historically treated LOG messages as low-priority during bootstrap and standalone operation. This has led to confusion and even masked a bug, because the normal expectation of code authors is that elog(LOG) will pu