Re: Snapshot synchronization, again...

Поиск
Список
Период
Сортировка
От Joachim Wieland
Тема Re: Snapshot synchronization, again...
Дата
Msg-id AANLkTi=m0-427u4hFDt1+Lzue13fJ_BNACgSAJtwwkZM@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Snapshot synchronization, again...  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: Snapshot synchronization, again...  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Snapshot synchronization, again...  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers
Hi,

On Mon, Feb 21, 2011 at 4:56 PM, Alvaro Herrera
<alvherre@commandprompt.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: David E. Wheeler
Дата:
Сообщение: Re: FDW API: don't like the EXPLAIN mechanism
Следующее
От: David E. Wheeler
Дата:
Сообщение: Re: FDW API: don't like the EXPLAIN mechanism