From: | Joachim Wieland <joe(at)mcknight(dot)de> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Snapshot synchronization, again... |
Date: | 2011-02-21 19:33:26 |
Message-ID: | AANLkTi=m0-427u4hFDt1+Lzue13fJ_BNACgSAJtwwkZM@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On Mon, Feb 21, 2011 at 4:56 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> What's the reason for this restriction?
> if (databaseId != MyDatabaseId)
> ereport(ERROR,
> (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> errmsg("cannot import snapshot from a different database")));
I just couldn't think of a use case for it and so didn't want to
introduce a feature that we might have to support in the future then.
> Why are we using bytea as the output format instead of text? The output
> is just plain text anyway, as can be seen by setting bytea_output to
> 'escape'. Perhaps there would be a value to using bytea if we were to
> pglz_compress the result, but would there be a point in doing so?
> Normally exported info should be short enough that it would cause more
> overhead than it would save anyway.
It is bytea because it should be thought of "just some data". It
should be regarded more as a token than as text and should not be
inspected/interpreted at all. If anybody decides to do so, fine, but
then they should not rely on the stability of the message format for
the future.
Joachim
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2011-02-21 20:19:20 | Re: FDW API: don't like the EXPLAIN mechanism |
Previous Message | David E. Wheeler | 2011-02-21 18:11:17 | Re: FDW API: don't like the EXPLAIN mechanism |