Re: Protocol buffer support for Postgres - Mailing list pgsql-hackers

From Paul Ramsey
Subject Re: Protocol buffer support for Postgres
Date
Msg-id CACowWR15v_Ej6NhoqWE=6J3pLs6BHWgZua5ZYq5CDZt4jLL3Vw@mail.gmail.com
Whole thread Raw
In response to Re: Protocol buffer support for Postgres  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Protocol buffer support for Postgres
Next
From: Dean Rasheed
Date:
Subject: Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.