Quantcast
Channel: perl.dbd.pg
Viewing all 134 articles
Browse latest View live

Test failing when compiling dbd-pg (1 message)

$
0
0
I am attempting to compile DBD::Pg from source on Mac OSX 10.8, and receiving the following error relating to the PrintWarn attribute.

Any help is greatly appreciated.

Lincoln

PGINITDB="/usr/local/pgsql/bin/initdb" PERL_DL_NONLAZY=1 /Users/lincoln/perl5/perlbrew/perls/perl-5.18.1/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/00_signature.t .... skipped: Set the environment variable TEST_SIGNATURE to enable this test
t/00basic.t ......... ok
t/01connect.t ....... Please wait, creating new database for testing
t/01connect.t ....... 1/15 #
# DBI Version 1.63
# DBD::Pg Version 2.19.3
# Perl Version 5.18.1
# OS darwin
# PostgreSQL (compiled) 90302
# PostgreSQL (target) 90302
# PostgreSQL (reported) PostgreSQL 9.3.2 on x86_64-apple-darwin12.5.0, compiled by i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00), 64-bit
# Default port 5432
# DBI_DSN dbi:Pg:db="postgres";port=5440;host=<pwd>/dbdpg_test_database/data/socket
# DBI_USER lincoln
# Test schema dbd_pg_testschema
# PGDATABASE mydb
# PGHOST /tmp
# PGPASSWORD
# PGUSER lincoln
# DBI_DRIVER Pg
# LANG C
# array_nulls on
# backslash_quote safe_encoding
# client_encoding UTF8
# server_encoding UTF8
# standard_conforming_strings on
# Adjusted: initdb
t/01connect.t ....... ok
t/01constants.t ..... ok
t/02attribs.t ....... 1/249
# Failed test 'DB handle attribute "PrintWarn" shows warnings when on'
# at t/02attribs.t line 263.
# ''
# doesn't match '(?^:dbd_pg_test_temp)'
(in cleanup) DBD::Pg::st DESTROY failed: no connection to the server at t/02attribs.t line 1558.
t/02attribs.t ....... 247/249 # Looks like you failed 1 test of 249.
t/02attribs.t ....... Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/249 subtests
t/03dbmethod.t ...... ok
t/03smethod.t ....... ok
t/04misc.t .......... 1/70 # Checking pg_st_split_statement. This may take a while...
t/04misc.t .......... ok
t/06bytea.t ......... ok
t/07copy.t .......... ok
t/08async.t ......... ok
t/09arrays.t ........ ok
t/12placeholders.t .. ok
t/20savepoints.t .... ok
t/99cleanup.t ....... 1/1 Removing test database directory
t/99cleanup.t ....... ok

Test Summary Report
-------------------
t/02attribs.t (Wstat: 256 Tests: 249 Failed: 1)
Failed test: 23
Non-zero exit status: 1
Files=15, Tests=1691, 28 wallclock secs ( 0.24 usr 0.04 sys + 4.87 cusr 1.63 csys = 6.78 CPU)
Result: FAIL
Failed 1/15 test programs. 1/1691 subtests failed.
make: *** [test_dynamic] Error 255


Version 3.0.0 released (1 message)

$
0
0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Version 3.0.0 of DBD::Pg, the Perl interface to Postgres,
has just been released. As you can see from the version
number, this is a major release. In addition to many
bugfixes and enhancements, the behavior of pg_enable_utf8
has been changed. The minimum versions of Perl (5.8.1)
and DBI (1.614) have been increased.

The new version is available from CPAN. Checksums:

58c2613bcb241279aca4c111ba16db48 DBD-Pg-3.0.0.tar.gz
03ded628d453718cbceaea906da3412df5a7137a DBD-Pg-3.0.0.tar.gz

The complete list of changes:

Version 3.0.0

- Major change in UTF-8 handling. If client_encoding is set to UTF-8,
always mark returned Perl strings as utf8. See the pg_enable_utf8 docs
for more information.
[Greg Sabino Mullane, David E. Wheeler, David Christensen]

- Bump DBI requirement to 1.614

- Bump Perl requirement to 5.8.1

- Add new handle attribute, switch_prepared, to control when we stop
using PQexecParams and start using PQexecPrepared. The default is 2:
in previous versions, the effective behavior was 1 (i.e. PQexecParams
was never used).
[Greg Sabino Mullane]

- Better handling of items inside of arrays, particularly bytea arrays.
[Greg Sabino Mullane] (CPAN bug #91454)

- Map SQL_CHAR back to bpchar, not char
[Greg Sabino Mullane, reported by H.Merijn Brand]

- Do not force oids to Perl ints
[Greg Sabino Mullane] (CPAN bug #85836)

- Return better sqlstate codes on fatal errors
[Rainer Weikusat]

- Better prepared statement names to avoid bug
[Spencer Sun] (CPAN bug #88827)

- Add pg_expression field to statistics_info output to show
functional index information
[Greg Sabino Mullane] (CPAN bug #76608)

- Adjust lo_import_with_oid check for 8.3
(CPAN bug #83145)

- Better handling of libpq errors to return SQLSTATE 08000
[Stephen Keller]

- Make sure CREATE TABLE .. AS SELECT returns rows in non do() cases

- Add support for AutoInactiveDestroy
[David Dick] (CPAN bug #68893)

- Fix ORDINAL_POSITION in foreign_key_info
[Dagfinn Ilmari Mannsker] (CPAN bug #88794)

- Fix foreign_key_info with unspecified schema
[Dagfinn Ilmari Mannsker] (CPAN bug #88787)

- Allow foreign_key_info to work when pg_expand_array is off
[Greg Sabino Mullane and Tim Bunce] (CPAN bug #51780)

- Remove math.h linking, as we no longer need it
(CPAN bug #79256)

- Spelling fixes
(CPAN bug #78168)

- Better wording for the AutoCommit docs
(CPAN bug #82536)

- Change NOTICE to DEBUG1 in t/02attribs.t test for handle attribute "PrintWarn":
implicit index creation is now quieter in Postgres.
[Erik Rijkers]

- Use correct SQL_BIGINT constant for int8
[Dagfinn Ilmari Mannsker]

- Fix assertion when binding array columns on debug perls >= 5.16
[Dagfinn Ilmari Mannsker]

- Adjust test to use 3 digit exponential values
[Greg Sabino Mullane] (CPAN bug #59449)

- Avoid reinstalling driver methods in threads
[Dagfinn Ilmari Mannsker] (CPAN bug #83638)

- Make sure App::Info does not prompt for pg_config location
if AUTOMATED_TESTING or PERL_MM_USE_DEFAULT is set
[David E. Wheeler] (CPAN bug #90799)

- Fix typo in docs for pg_placeholder_dollaronly
[Bryan Carpenter] (CPAN bug #91400)

- Cleanup dangling largeobjects in tests
[Fitz Elliott] (CPAN bug #92212)

- Fix skip test counting in t/09arrays.t
[Greg Sabino Mullane] (CPAN bug #79544)

- Explicitly specify en_US for spell checking
[Dagfinn Ilmari Mannsker] (CPAN bug #91804)


- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201402050932
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAlLyS34ACgkQvJuQZxSWSsjLcgCeM413ALNdM7rj4SfYMnyEmee5
VtAAnj56tNtWoK9dWJKVg1wHgTsXBXok
=6wwX
-----END PGP SIGNATURE-----


Disable encryption of this mailing list on Gmane (2 messages)

$
0
0
Hi,

I read this mailing list mostly on Gmane, but unfortunately
it is tagged as "encrypt" there which means that mail ad-
dresses are mangled so for replies I need to access
nntp.perl.org in parallel to compose, eh, not-so-ugly
mails :-).

Could this be changed, please? To do so, an administrator
needs to go to
http://gmane.org/info.php?group=gmane.comp.db.postgresql.dbdpg&edit=t,
remove "encrypt" from "Encode", add his mail address and a
short comment and hit "Submit".

Thanks!
Tim

DBD::Pg version 3.1.0 released (1 message)

$
0
0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160


Version 3.1.0 of DBD::Pg has been released. Only a couple small
changes, but no point in sitting on them too long! To wit:

Version 3.1.0 Released April 4, 2014 (git commit 26517a3531f93de79375a02da45a79789cd3caae)

- Make sure UTF-8 enabled notifications are handled correctly
[Greg Sabino Mullane]

- Allow "WITH" and "VALUES" as valid words starting a DML statement
[Greg Sabino Mullane] (CPAN bug #92724)


Checksums:
dc350b9eeb5316e2ae0f574a64ff333c DBD-Pg-3.1.0.tar.gz
322b201281949afb55cbdfdf78e89618053f16f5 DBD-Pg-3.1.0.tar.gz

- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201404050751
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAlM/7l0ACgkQvJuQZxSWSshCGwCgwlgot6LfYe0pxenSem029k9R
EIIAn0r0IEdyoI0afVcXOWlaGY2D3Kjc
=tc9x
-----END PGP SIGNATURE-----


Characterset problem (4 messages)

$
0
0
Hello everyone!

I'm new to this group so I hope I don't begin with any faux pas.

I have a problem and don't seem to be able to make any headway with it.

I have been using Arch Linux and Perl DBI/DBD for Postgresql quite
happily now for years. My database contains German special characters
and I have configured Arch Linux to use UTF-8. Everything was fine
until Arch upgraded to DBD 3.0. DBI/DBD still worked well for INSERT
statements, but the results of SELECT statements are now ISO-8859 8 bit
characters. This has not changed after the release of DBD version 3.1.
The simple work-around to the re-install the Arch package
perl-dbd-pg-2.19.3-2-x86_64.pkg.tar.xz; that restores the correct
behaviour. This is why I concluded that the problem probably lies with
DBD and not DBI for Postgresql.

In my select statements I even have explicitly:

SET CLIENT_ENCODING TO 'UTF8';

I would be grateful for any pointers

As a Kiwi in Germany I have a rather odd locale, namely:

LANG=en_NZ.UTF-8
LC_CTYPE=en_NZ.UTF-8
LC_NUMERIC="en_NZ.UTF-8"
LC_TIME=en_DK.UTF-8
LC_COLLATE="en_NZ.UTF-8"
LC_MONETARY=en_IE.UTF-8
LC_MESSAGES="en_NZ.UTF-8"
LC_PAPER="en_NZ.UTF-8"
LC_NAME="en_NZ.UTF-8"
LC_ADDRESS="en_NZ.UTF-8"
LC_TELEPHONE="en_NZ.UTF-8"
LC_MEASUREMENT="en_NZ.UTF-8"
LC_IDENTIFICATION="en_NZ.UTF-8"
LC_ALL=

Yours,
Mike Dowling

--
Dr. Michael L. Dowling
Gaußstr. 27
38106 Braunschweig
Germany

colon (:) placeholders and array slices (2 messages)

$
0
0
Hi all,

I am having trouble with array slices in DBD::Pg. I'm migrating a large code base from Pg to DBD::Pg and we'd like to use ? as a placeholder as this is the accepted standard in the DBI world. Unfortunately we have some queries with array slices that are being recognized by DBD::Pg as placeholders. I can turn this off by setting pg_placeholder_dollaronly, but then we loose the ? as a placeholder. After discussing this with Greg Mullane, I sent a pull request that would allow me to turn off colon placeholders only:

https://github.com/bucardo/dbdpg/pull/2

On reflection Greg felt that it might be better to do some smarter parsing so that array slices could be used along with colon placeholders. A couple of suggestions were made:

1. a colon followed by a number /\d:\d/ would not be recognized as a placeholder
2. only colons followed by a space /\s:\d/ would be recognized as a placeholder

Either way both of these would work as intended:

SELECT bar[1:2] FROM foo WHERE baz = ?
SELECT bar FROM foo where baz = :1

I am not fussed either way, so long as we can use an array slice and ? placeholders at the same time. I feel like the solution lest likely to break anyone's existing code is the original solution of providing an option of turning off colon place holders. Here are some queries that are problematic with a colon place holder as restricted by either 1 or 2 from above:

SELECT bar[(select 1):2] FROM foo WHERE baz = ?
:2 is treated incorrectly as a placeholder if option 1 above is used

SELECT bar[1 :2] FROM foo WHERE baz = ?
:2 would be treated incorrectly as a placeholder

INSERT INTO foo (bar) VALUES (:1)
:1 would be a syntax error (I think?) unless /\(:\d/ where also an exception

Rudolf Lippan also chimed in pointing out that older versions of DBD::Pg correctly differentiated between array slices and colon placeholders as of at least version 1.31.

This is related to rt#95173, a bug I opened last week, which can be seen here:

https://rt.cpan.org/Public/Bug/Display.html?id=95173

I would like to gauge how other interested parties might feel about this.

Thanks,
Graham

further fix needed to restore PGINITDB testing (1 message)

$
0
0
Patch attached is needed in addition to e25f0369332c3ace to restore
PGINITDB testing.

Nicholas Clark

avoid dTHX where possible (it's relatively expensive) (4 messages)

$
0
0
Attached are two patches that remove use of dTHX in functions in quote.c
and types.c

dTHX is ithreads only, but relatively expensive, as it needs to make a
function call to retreive a value from thread local storage. It's much
better to pass that value as a function parameter, as the caller will have
it already.

Tested for (almost) everything ithreads and not from 5.8.1 to 5.18.2

I can't see how to make the same change to dbdimp.c without also changing
Driver.xst to optionaly support it.

Nicholas Clark

DBD::Pg version 3.2.1 released (Perl Postgres driver) (1 message)

$
0
0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160


Version 3.2.1 of DBD::Pg, the Perl interface to Postgres,
has just been released. In addition to some bug fixes,
there is a new handle attribute called pg_placeholder_nocolons.
When set, it will prevent the colon character from being picked
up as a placeholder. More information can be found at:

http://blog.endpoint.com/2014/05/dbdpg-array-slices-and.html

The new version is available from CPAN:

http://search.cpan.org/dist/DBD-Pg/

hecksums:

6f2196ddd75d613e37a57e1ed7f0bcfc DBD-Pg-3.2.1.tar.gz
ddcef35e7431742258a415069c9f1c2d303c0446 DBD-Pg-3.2.1.tar.gz

- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201405251417
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAlOCNXgACgkQvJuQZxSWSsgmjgCg2cqODzZF5ZJuZsUUJ2F6IeF6
LD8AnjtVS2AOhnEOZPHZg1wWLBMKNmDQ
=yw6M
-----END PGP SIGNATURE-----



DBD::Pg 3.3.0 released (driver for Postgres) (1 message)

$
0
0
Version 3.3.0 of DBD::Pg, DBI driver for PostgreSQL, is
now available. This release enhances UTF-8 support a
great deal, thanks to the work of Dagfinn Ilmari Mannsåker
and Nicholas Clark. As always, you can find it on CPAN at:

http://search.cpan.org/dist/DBD-Pg/

Checksums:

547de1382a47d66872912fe64282ff55 DBD-Pg-3.3.0.tar.gz
9ec52d0d75463e6a448760e2d2fcbc41ca6201e1 DBD-Pg-3.3.0.tar.gz

Complete list of changes:

Version 3.3.0 Released May 31, 2014 (git commit 055f788cf96b380b9fe0e80b6cedb88f8d1799b8)

- Major cleanup of UTF-8 support:
Fix quoting of UTF-8 values
Add support for UTF-8 statement strings
Fix UTF-8 support in placeholders and return values
[Dagfinn Ilmari Mannsåker] (CPAN bug #95214 and #91655)
Test that the Pg server agrees with us about the lengths of input strings.
Refactor Unicode test to use anon hashes to describe the tests to run.
Test pg_enable_utf8 of -1, in addition to 0 and 1.
Extend the Unicode round-trip tests to verify ASCII, BMP and non-BMP code points.
Test that characters created in the server reach the client correctly.

- Rewrite foreign_key_info to be just one query
[Dagfinn Ilmari Mannsåker]

- Remove ODBC support from foreign_key_info
[Dagfinn Ilmari Mannsåker]

- Remove use of dTHX in functions in quote.c and types.c
[Nicholas Clark]

--
Greg Sabino Mullane greg@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201406021322
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

Is there a way to abort a long COPY? (2 messages)

$
0
0
Hi! I'm reading a lot of data from a database using the "COPY
(SELECT...) TO STDOUT" method but occasionally I need to abort the
process mid-way. When doing that, it seems that the COPY process
continues on the server, long after I have disconnected from the
database in my script. Is there a way to tell the server to abort the
COPY?

$sth->finish() does not seem to do anything about it.

I'm using DBD::Pg 2.19.2 in my script and PostgreSQL 9.1 on the server
if that makes a difference.

// Anders

DBD::Pg 3.4.0 released (1 message)

$
0
0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Version 3.4.0 of DBD::Pg, the Perl interface to Postgres,
was released on August 16, 2014. The primary changes in this
version are improvements in the table_info() and column_info()
methods: see below for details. As always, you can download
a tarball from CPAN:

http://search.cpan.org/dist/DBD-Pg/

Checksums for version 3.4.0 of DBD::Pg

e1fbe2ac4bd4951f1726a36b315c263c DBD-Pg-3.4.0.tar.gz
611cda7b4eefcc437991eebb4a1561a112554c18 DBD-Pg-3.4.0.tar.gz

The mailing list welcomes any and all questions:

http://www.nntp.perl.org/group/perl.dbd.pg/

Development can be tracked via git:

git://bucardo.org/dbdpg.git

Complete list of changes in 3.4.0:

(git commit 7a5da12d84b4c2e9879f90fb6168f56c095071fa)

- Cleanup and improve table_info()
[Mike Pomraning <mjp@pilcrow.madison.wi.us>] (github issue #7)

table_info() type searching now supports TABLE, VIEW, SYSTEM TABLE,
SYSTEM VIEW, and LOCAL TEMPORARY

table_info() object searching fully supports the above types.

table_info() object searching no longer ignores invalid types - a filter
of 'NOSUCH' will return no rows, and 'NOSUCH,LOCAL TEMPORARY' will
return only temp objects.

tableinfo() type filters are strictly matched now ... previously a
search for SYSTEM TABLE would have fetched plain TABLE objects.

table_info() now treats temporary tables and temporary views as LOCAL TEMPORARY

- Make sure column_info() and table_info() can handle materialized views.
[Greg Sabino Mullane] (CPAN bug #97032)


- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 201408181051
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAlPyEwYACgkQvJuQZxSWSsgBBQCgrYkYnb9Sgv4G5yQJYNQqIOfj
VhkAn2bxny/zVJBOFvOJ/w/AtajXgO52
=70S2
-----END PGP SIGNATURE-----


Interest in serializing composite types? (25 messages)

$
0
0
Hi everyone;

I am nearing completion on the logic to serialize composite types into
textual representation of tuples for LedgerSMB and I am wondering if there
is additional interest from others who use DBD::Pg. If there is we would
certainly release the logic and interfaces on CPAN. So I figured I would
ask.

For those who would be interested, I guess I have a few questions:

1. Do you need Moose or Moo support?
2. Do you need plain old hashref support?
3. Do you need bytea support?

If this is unwelcome please ignore but this seemed like a good place to ask
since it is PostgreSQL/Perl-specific and many of you might have thought
about using composite types in this way.

In case it isn't clear what I am talking about is:

given a type:

CREATE TYPE foo (
bar text,
baz text
);

and a hashref {bar => 'foo', baz => 'this, or else that'}

it should produce (foo,"this, or else that")

--
Best Wishes,
Chris Travers

Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more

Composite type serialization update (1 message)

$
0
0
Hi;

I have released the cpan modules which handle serialization and
deserialization. The logic is currently spread between three modules. I
would be happy to try to help refactor some of the logic into DBD::Pg if it
belongs there (specific proposals below). And while the code is not really
where I want it, it currently works. In coming weeks you can expect
refactoring and an improved API between the components.

The logic is currently spread between four modules:

1. PGObject::Type::Composite has a basic API for learning db structure
associated on a db level, serializing and deserializing.

2. PGObject::Util::PseudoCSV parses the tuple and array formats. This
necessarily duplicates some functionality in DBD::Pg, so wondering about
making the array parsing code there more general and a public API
(something like $dbh->parse_literal($string)) and getting rid of this
module entirely.

3. PGObject::Util::Catalog::Types provides a functional interface to the
type catalogs. Currently this is limited to type lookups but there are
plans to add ddl facilities as well.

4. PGObject has a registry system which allows detection of
auto-serializable data types to the db (if it has a to_db() method, we call
it). It also allows for custom types to be registered for handling data
retrieved from the db. So for example numeric can be mapped to a subclass
of Math::BigFloat providing the necessary interfaces and conversion will
happen on retrieval. I don't know if this would be worth adding to DBD::Pg
but if there is interest I could do that.

Having the type registry at a lower level would make things more consistent
since one could register a type and have it handled regardless of whether
the query is a stored proc called from PGObject or otherwise.

--
Best Wishes,
Chris Travers

Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more

DBD::Pg 3.4.2 released (1 message)

$
0
0

Version 3.4.2 of DBD::Pg, DBI driver for PostgreSQL, is
now available. This release (along with 3.4.1) provides
some small fixes for the table_info() method. Get it here:

http://search.cpan.org/dist/DBD-Pg/

Checksums:

e8e92d86e6fd99f702da9a51d9970d87 DBD-Pg-3.4.2.tar.gz
aa8b141ec0318153d65689f9072dfd2a3f76f57b DBD-Pg-3.4.2.tar.gz

Complete list of changes:

Version 3.4.2 Released September 25, 2015
(git commit 61440e1f4ccb6c293c5838676da1942e0df67271)

- Fix bug where single-quoted type arguments to the table_info()
method were causing a SQL error.
[Greg Sabino Mullane] (CPAN bug #99144)


Version 3.4.1 Released August 20, 2014
(git commit cfd146effde09c493ac7573408ac29d6d9cbed47)

- Allow '%' again for the type in table_info() and thus tables()
It's not documented or tested in DBI, but it used to work until
DBD::Pg 3.4.0, and the change broke DBIx::Class::Schema::Loader, which
uses type='%'.
[Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>]


--
Greg Sabino Mullane greg@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201409281133
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8



Memory leaks when fetching array columns (8 messages)

$
0
0
Hello DBD-Pg!

I've been struggling now for a few days with leaking memory in my long
running Perl script. Step by step I narrowed the source of the leak. And it
turned out to be the fetching of array ( text[] ) column from a postgresql
db. I tried: using fetchall_hashref( {} ), other variations of fetchall,
all variations of fetchrow_*, prepare vs prepare_cached, prepare+fetch_* vs
selectall_*. The result is always the same. If I remove the array column
from SELECT then the memory leak goes away. I detect the memory leak with
Devel::Monitor by comparing number of new SVs before and after the queries
- and I do it multiple times which shows that this number is only
increasing over time.

I found few thread on the internet reporting some leaks related to
fetchall_* etc. but these didn't suggest any working solution.

Is this a known problem? Am I doing something wrong? Would you have advice
how to fix it?

Thank you in advance,
Kris

DBD::Pg 3.5.0 released (driver for Postgres) (1 message)

$
0
0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160


Version 3.5.0 of DBD::Pg, DBI driver for PostgreSQL, is
now available. This release contains two major changes:
an improved ping() method, and support for the new
backslash-escape for placeholders.

The ping() method now tries much harder to detect if the
backend is still there. Previously, there was a chance of
returning false positives, especially if inside of an open
transaction.

DBD::Pg now supports The use of a backslash character before a
placeholder - this will prevent the character after the backslash
from being treated as a placeholder.The most important and immediate
use for this is in escaping question marks, which are used in
Postgres as JSON operators (among other things). To use, just put
the backslash before a question mark, and DBD::Pg will strip the
backslash and send the question mark directly to the backend. Make
sure you use two backslashes if inside a quoted string of course.

Version 3.5.0 of DBD::Pg can be downloaded here:

http://search.cpan.org/dist/DBD-Pg/

Checksums:

16cea4efcd1f8917679920be50e23da9 DBD-Pg-3.5.0.tar.gz
5c784db28c12f9b7f9b7e9f34623c663342d0e57 DBD-Pg-3.5.0.tar.gz

Complete list of changes:

Version 3.5.0 Released January 6, 2015 (git commit bb13d3306fd1c73fac1c0c8a330c14e6b8443942)

- Allow "placeholder escaping" by the use of a backslash directly before it, e.g.
"SELECT 1 FROM jsontable WHERE foo \\? ?"
will contain a single placeholder, and the first question mark will be sent directly
to the backend to be parsed as an operator.
[Greg Sabino Mullane, Tim Bunce]
(CPAN bug #101030)

- Improve the workings of the ping() method, so it always tests for
a valid database backend and returns the correct true/false.
[Greg Sabino Mullane, with help from Andrew Gierth and Tim Bunce]
(CPAN bug #100648)

- Add get_info(9000) => 1 to indicate driver can escape placeholders.
[Tim Bunce]

- In tests, force the client_encoding to UTF8, skip tests that involve
characters not supported by the server_encoding
[Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>]

- Fix memory leak when selecting from arrays
[Dagfinn Ilmari Mannsåker, reported by Krystian Samp]

- Make get_info much more efficient and slightly simpler.
[Tim Bunce]

- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201501071032
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAlStUfwACgkQvJuQZxSWSsgF1gCdGBZay32O2cU9hsF2BYF86+r/
Py8AoObBv0+nSGTwgvo1obt8bg3V3Aze
=wklb
-----END PGP SIGNATURE-----


DBD::Pg 3.5.1 released (1 message)

$
0
0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Version 3.5.1 of DBD::Pg, DBI driver for PostgreSQL, is
now available. This release contains some minor fixes to
the code, the tests, and the documentation.

Version 3.5.1 of DBD::Pg can be downloaded here:

http://search.cpan.org/dist/DBD-Pg/

Checksums:

cc693c034e7a31d1bf85ecb5ab9f3571 DBD-Pg-3.5.1.tar.gz
2d3369a007f9acb3c1e3011030d7167bea3c5995 DBD-Pg-3.5.1.tar.gz

Complete list of changes:

Version 3.5.1 Released February 17, 2015
(git commit 6c3457ee20c19ae492d29c490af6800e7e6a0774)

- Prevent core dump if the second argument to the quote() method
is anything but a hashref
[Greg Sabino Mullane]
(CPAN bug #101980)

- Better "support" for SQL_ASCII servers in the tests.
Allow env var DBDPG_TEST_ALWAYS_ENV to force use of DBI_DSN and DBI_USER in tests.
[Greg Sabino Mullane]

- Fix client_encoding detection on pre-9.1 servers
[Dagfinn Ilmari Mannsåker]

- Fix operator existence check in tests on pre-8.3 servers
[Dagfinn Ilmari Mannsåker]

- Documentation fix
[Stuart A Johnston]

- Fix pg_switch_prepared database handle documentation
[Dagfinn Ilmari Mannsåker]

- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201502181944
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAlTlOXUACgkQvJuQZxSWSshAnwCg12tSSLU1LoV7EJt8f9gdNj5O
Td4AoKT/OdvNKXeE+x09WTfXfFKY4KmY
=eAsf
-----END PGP SIGNATURE-----


Re: Making DBD::Pg to return Postgres arrays as Perl arrays (8 messages)

$
0
0
I wrote:

> When I insert new rows where the field has a Perl-array as the value,
> DBIx::Class+DBD::Pg automatically stores them in the database, as hoped
> - nice!

> But when I read the field again, I get the textual "Postgres-encoded"
> representation back (i.e. a string like '{"(a,b,c)","(d,e,f)"}').

After looking more closely on this:

Simple arrays work out of the box, i.e. text[] I can read/write and
values are automatically converted from Perl arrays when writing to the
database, and converted back to Perl arrays when reading.

The problem I have is only when my datatype is a (custom) tuple.

I.e. in Postgres I have:

CREATE TYPE entry AS (tag TEXT, created TIMESTAMP, notes TEXT, initials TEXT);
ALTER TABLE vehicle ADD COLUMN entrylist entry ARRAY;

I would like to be able to do:

$schema->resultset('Vehicle')->create({ entrylist=>[
[ 'a', '2015-05-07', 'info', 'adsj' ],
[ 'b', '2015-05-07', 'more', 'adsj' ],
] });

and I was hoping that there was a way to configure DBIx::Class/DBD::Pg
for that to work (it doesn't, the list-ref of list-refs gets sent to the
database as '{{"a",...},{"b",...}}' which should be '{("a",...),("b",...)}',
and Postgres complains).

... and I was hoping that when reading from the database, I could
automatically get a list-ref of list-refs back.

Maybe I was hoping for too much - I just wanted to check that I wasn't
missing something obvious, before hacking together a parser for
Postgres' format.

Best regards,

Adam

Adding Cc to the DBD::Pg mailing list, as it now looks to me to perhaps
not just be me not configuring DBIx::Class properly.

--
Adam Sjøgren
adsj@novozymes.com

DBD:Pg problems (2 messages)

Viewing all 134 articles
Browse latest View live


Latest Images