Re: Protocol buffer support for Postgres

Поиск
Список
Период
Сортировка
От Paul Ramsey
Тема Re: Protocol buffer support for Postgres
Дата
Msg-id CACowWR15v_Ej6NhoqWE=6J3pLs6BHWgZua5ZYq5CDZt4jLL3Vw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Protocol buffer support for Postgres  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, Apr 26, 2016 at 6:40 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Craig Ringer <craig@2ndquadrant.com> writes:
>> On 26 April 2016 at 14:06, 陈天舟 <tianzhouchen@gmail.com> wrote:
>>> (1) Since each protocol buffer column requires a schema. I am not sure
>>> where is the best place to store that schema info. Should it be in a
>>> CONSTRAINT (but I am not able to find the doc referring any custom
>>> constraint), or should it be in the COMMENT or somewhere else?
>
>> I can't really imagine how you'd do that without adding a new catalog like
>> we have for enum members. A typmod isn't sufficient since you need a whole
>> lot more than an integer, and typmods aren't tracked throughout the server
>> that well.
>
>> That'll make it hard to do it with an extension.
>
> PostGIS manages to reference quite a lot of schema-like information via
> a geometry column's typmod.  Maybe there's a reason why their approach
> wouldn't be a good fit for this, but it'd be worth investigating.

We pack a short type number, two flags and 24 bits of SRID number into
an integer. The SRID number is in turn a foreign key into the
spatial_ref_sys table where the fully spelled out spatial reference
definition lives.  It's not very nice, and it's quite breakable since
there's no foreign key integrity between the typmod and the
spatial_ref_sys pk.

P.



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Protocol buffer support for Postgres
Следующее
От: Dean Rasheed
Дата:
Сообщение: Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.