binary compat

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: binary compat
Date: 2009-09-01 07:45:35
Message-ID: m2d46b3y74.fsf@hi-media.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

I've been idly thinking about binary COPY and recent performance efforts
spent on it. The main problem I have with binary output is that I never
know when it'll be any useful (except very same hardware and PostgreSQL
setup)... useful meaning I get to read it back into some database.

Would providing the following two functions help?

SELECT * FROM pg_binary_compat();
-> version, timestamp ondisk format, architecture, you name it

SELECT pg_binary_compat(version, timestamp ondisk format, ...)
-> bool

Equiped with this I would first setup a (somewhat portable) virtual
machine where I'm sure I'm able to load the binary files, then get to
use COPY BINARY everywhere possible: I have a way to easily tell when
not to use it. First example would be to teach londiste about this...

Now writing the function doesn't sound a lot of fun, but I don't know
what to compare to be able to decide whether COPY output will get read
correctly on input. It even looks to me like in some cases this would
work accross major PostgreSQL versions? Or would that depend on used
types, so we'd need a variant taking those into consideration?

Anyone interrested in spelling out the checks to get done to implement
the functions, or to implementing it, provided there's no obvious reason
why it can not be made trustworthy?

Regards,
--
dim

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2009-09-01 08:13:54 Re: autovacuum launcher using InitPostgres
Previous Message Simon Riggs 2009-09-01 07:43:58 Re: remove flatfiles.c