Re: 64-bit API for large objects

Mark,

If you don't mind contributing the changes, we'd be glad to take a look at
them. Thanks.

-Jonah

On 9/18/05, Mark Dilger <pgsql(at)markdilger(dot)com> wrote:
>
> My company has written a 64-bit large object API, extending the postgresql
> server to be able to read/write/seek/tell/open/close objects larger than
> 2GB.
> If the hackers community considers this valuable, we will submit the
> changes
> back for the rest of the community to share.
>
>
> From one of my programmers, Jeremy Drake:
>
> I tested this out on my box with a 4gb dvd iso image, and it appears to
> work correctly. The test code I found for large object things does not
> really seem to exercise the api very well though. And the regression
> tests do not seem to even touch large objects (they all still pass after
> this change).
>
> Mark, can you take a look at this and make sure I haven't broken anything
> too obviously?
>
> I wrote it into the same file as the large object code, since that file
> has some static stuff for caching things which I would like to share. I
> opted to add new functions tell64 and seek64 rather than changing the
> existing ones for backwards compatibility. I plugged them into the
> pg_proc catalog, but everything in that file has an explicit OID, and I do
> not feel comfortable (yet) grabbing up OIDs for stuff. So I set them to
> an OID of zero, which means the scripts will assign it one which is not
> used (in the range 10000-something). Since the convention is that such
> functions have explicit assigned OIDs, it would probably be required to
> get real ones if this were ever to be submitted back. Also, in the libpq
> stuff, at the moment I have it fail if it cannot find the seek64 or tell64
> functions. It may be best to have it work as long as you don't try to
> call them, in order to preserve backwards compatibility with other server
> versions.
>
> If you think this is a reasonable patch, it might be nice to send it to
> them, be a good neighbor and all that...
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>

--
Respectfully,

Jonah H. Harris, Database Internals Architect
EnterpriseDB Corporation
http://www.enterprisedb.com/