Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2010-10

PostgreSQL 8.4.5 Ubuntu 10.10 x64 and bytea=blobs up to 1 gigabyte

8 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Andrew Brunner

Looking to get some resolution to an immediate problem with postgres component I have...

Field definitions for blob can be mapped to bytea and enable support for blob data as I am pretty sure byte for byte output/input would suffice. Some debugging may be needed to make sure we don't need escape/unescape on string literals. I'm hoping for a quick fix.

As is right now, the postgres DBMS system if offline limits b/c I happen to rely heavliy on Field/Paramter).AsBlob:=[] in my code for arrays[n] of Int64 where each element is 8 bytes long. MySQL did this flawlessly. What's it gonna take to remove the restriction and map the field to bytea?

http://bugs.freepascal.org/view.php?id=17693

Reply by email

Michael Van Canneyt
to Andrew Brunner: Looking to get some resolution to an immediate problem with postgres component I have...…
Andrew Brunner wrote 7 lines
Looking to get some resolution to an immediate problem with postgres component I have... Field definitions for blob can be mapped to bytea and enable support for blob data as I am pretty sure byte for byte output/input would suffice. Some debugging may be needed to make sure we don't need escape/unescape on string literals. I'm hoping for a quick fix.

I committed a fix in 16203, please test.

Show quoted text 6 lines
As is right now, the postgres DBMS system if offline limits b/c I happen to rely heavliy on Field/Paramter).AsBlob:=[] in my code for arrays[n] of Int64 where each element is 8 bytes long. MySQL did this flawlessly. What's it gonna take to remove the restriction and map the field to bytea?

Well, a 'please' usually does it in this part of the world.

Michael.

Reply by email

Martin Schreiber
to Michael Van Canneyt
Michael Van Canneyt wrote 11 lines
On Fri, 22 Oct 2010, Andrew Brunner wrote: > Looking to get some resolution to an immediate problem with postgres > component I have... > > Field definitions for blob can be mapped to bytea and enable support > for blob data as I am pretty sure byte for byte output/input would > suffice. Some debugging may be needed to make sure we don't need > escape/unescape on string literals. I'm hoping for a quick fix. I committed a fix in 16203, please test.

Please don't forget to mark bytea parameters as binary or use hex notation, otherwise the data probably will be cut by the first zero or even not accepted because of encoding errors.

Martin

Reply by email

Michael Van Canneyt
to Martin Schreiber: Please don't forget to mark bytea parameters as binary or use hex notation, otherwise the…
Martin Schreiber wrote 15 lines
On Saturday, 23. October 2010 13.11:01 Michael Van Canneyt wrote: > On Fri, 22 Oct 2010, Andrew Brunner wrote: >> Looking to get some resolution to an immediate problem with postgres >> component I have... >> >> Field definitions for blob can be mapped to bytea and enable support >> for blob data as I am pretty sure byte for byte output/input would >> suffice. Some debugging may be needed to make sure we don't need >> escape/unescape on string literals. I'm hoping for a quick fix. > > I committed a fix in 16203, please test. > Please don't forget to mark bytea parameters as binary or use hex notation, otherwise the data probably will be cut by the first zero or even not accepted because of encoding errors.

Thanks for the tip.
Done in rev. 16207, had a sneak peak at your implementation for it.

(I don't use postgres myself, so any testing will be welcome)

Michael.

Reply by email

Andrew Brunner
to Andrew Brunner: Updating and testing... Thanks Martin and Michael !

Parameter binding on update sql appears to be working. I traced into

Taking a 24 element array of Int64 yields 192 bytes. The size of the data was 193 (always adding 1 byte to the packet).

On Reading I presently only get a 1 byte so it's not enough to read in an actual element of int64 to see if we're even close.

Checking the DataLength for that record.field yields... Gotta do more work to find length of field...

Reply by email

Andrew Brunner
to Andrew Brunner

I did get a chance to test it and so far, though I haven't tried all my custom data types supported in my API, I was able to get my Int64 Array to read and write via this new version. So far so good. Thanks again!

Reply by email