{5} Assigned, Active Tickets by Owner (Full Description) (11 matches)

Joris van Zwieten requests support for postgres array types.

At the moment arrays can only be manipulated and queried in SQL, or generated and parsed as text. It would be nice to help users get around the latter if we can.

Container and stream interfaces seem the most appropriate. We'd want to be able to construct input arrays from either a field or a string.

There are a few gotchas:

• Separators between array elements are defined by the contained type. Usually the comma separates elements, but the Box type for example uses a semicolon. It could be anything. We'll have to query that at runtime, and cache the information somehow.
• Arrays can be nested. We'd probably want to check that all elements are arrays (or nulls) before going into deeper nesting levels.
• Quoting of array elements may be awkward--we'd have to have separate "treatments" just like we do for prepared statements.
• How do we specify nulls when creating an array?
• There is no real "end" to an array: there just comes a point where all else is null. On the C++ end we'd probably want more C++-like semantics, setting end() just past the last non-null element. But what if the last element in an array is null? Programs may break if they hit an unexpected end. We'd need more tolerant semantics: X.end()+1==X.end() and X.end()->is_null()==true.
• It would be nice to allow direct array indexing in a result ("r[row][col][i]") but it does complicate the result class a bit further.
• Array lengths aren't enforced by the backend (at least not in 8.2). It's tempting to stick to an array's declared length, but if we do, we must still accept out-of-bounds addressing.

Finally there is the encoding problem in the case of arrays of strings (or arrays of arrays of strings etc.). Parsing a string as an array of strings can go haywire in multibyte encodings that allow byte values equivalent to the closing quote inside a multibyte character. To get around that we'd need to know at least where the character boundaries are--which in turn depends on the encoding being used.

I was looking for a way to retrieve bytea data from a result without copying it. I tried to use fieldstream using libpqxx-2.6.8 but I got escaped data.

I don't know it it's a bug (I hope so). If it is not, how do I retrieve bytea data without using much more than bytea data size of memory?

This is roughly code I used:

result R;
...
pqxx::fieldstream file_data(R.at(0)["file_data"]);
#define CACHESIZE (0x7fff) /* minimum POSIX limit for read cache size */
char data_cache[CACHESIZE];
ofstream out;
out.exceptions(ofstream::failbit | ofstream::badbit);
out.open("filename", ios::binary);
while ( file_data.good() && out.good() ) {
    file_data.read(data_cache, CACHESIZE);
    out.write(data_cache, file_data.gcount());
}
out.close();

Using MSVC8.0 on WindowsXP, I compiled succesfully postgresql8.3.5, and also compiled successfully libpqxx as the command "nmake /f win32/vc-libpqxx.mak ALL" has not reported any error: in fact all the compilation went fine up to the paragraph in win32/INSTALL.txt:

"After that, it is recommended that you compile and run the self-test programs included in the package. ...."

After that, the problem is that when I try to compile the test suite I get:

F:\libpqxx-3.0>nmake /f win32\vc-test.mak ALL

Microsoft (R) Program Maintenance Utility Version 8.00.50727.762 Copyright (C) Microsoft Corporation. All rights reserved.

NMAKE : fatal error U1073: don't know how to make 'runner' Stop.

I tryed to regenerate the vc-test.mak file from its template in vc-test.mak.template with the tools/template2mak.py, but the resultant file is identical (only some slashes became back slashes :))

How to fix this problem and run the tests?

Thanks, Luca

The README is getting uncomfortably long, and it would be nice to have somewhat richer markup in that file.

This ought to be done on the wiki, and exported as HTML for inclusion in the distribution archive.

A new libpq function has been proposed, PQescapeIdentifier(), that will escape strings for use in identifiers (rather than for use in strings as the PQescapeString() functions do).

Once this happens, we should use it for cursors and other objects that the client program can suggest names for; and probably we should export the function as well.