On Fri, Jun 24, 2016 at 2:23 PM, Flavius Anton wrote:
> Any other thoughts on this? My guess is that it might be an important
> addition to Postgres that can attract even more users, but I am not
> sure if there's enough interest from the community. If I want to pick
> this task, how should I move
On Fri, Jun 24, 2016 at 11:35 AM, Álvaro Hernández Tortosa
wrote:
>
>
> On 24/06/16 14:23, Flavius Anton wrote:
>>
>> On Thu, Jun 23, 2016 at 2:54 PM, Flavius Anton
>> wrote:
>>>
>>> On Thu, Jun 23, 2016 at 1:50 PM, Greg Stark wrote:
On Thu, Jun 23, 2016 at 8:15 PM, Flavius Anton
On 24/06/16 14:23, Flavius Anton wrote:
On Thu, Jun 23, 2016 at 2:54 PM, Flavius Anton wrote:
On Thu, Jun 23, 2016 at 1:50 PM, Greg Stark wrote:
On Thu, Jun 23, 2016 at 8:15 PM, Flavius Anton wrote:
I'd love to talk more about this.
I thought quite a bit about this a few years ago but ne
On Thu, Jun 23, 2016 at 2:54 PM, Flavius Anton wrote:
> On Thu, Jun 23, 2016 at 1:50 PM, Greg Stark wrote:
>> On Thu, Jun 23, 2016 at 8:15 PM, Flavius Anton wrote:
>>>
>>> I'd love to talk more about this.
>>
>> I thought quite a bit about this a few years ago but never really
>> picked up it to
On Thu, Jun 23, 2016 at 1:50 PM, Greg Stark wrote:
> On Thu, Jun 23, 2016 at 8:15 PM, Flavius Anton wrote:
>>
>> I'd love to talk more about this.
>
> I thought quite a bit about this a few years ago but never really
> picked up it to work on.
>
> Another option would be to allow the output of yo
On Thu, Jun 23, 2016 at 8:15 PM, Flavius Anton wrote:
>
> I'd love to talk more about this.
I thought quite a bit about this a few years ago but never really
picked up it to work on.
There are different use cases where this could be useful and different
approaches that could be useful for the di
On Tue, Apr 26, 2016 at 2:40:49PM -0700, David Fetter wrote:
> Should we see about making a more flexible serialization
> infrastructure? What we have is mostly /ad hoc/, and has already
> caused real pain to the PostGIS folks, this even after some pretty
> significant and successful efforts were
On Mon, Apr 25, 2016 at 11:06:11PM -0700, 陈天舟 wrote:
> I am interested in adding Protocol Buffer support for Postgres. Protocol
> Buffer occupies less space than JSON. More importantly, it has schema and
> is forward/backward compatible. All these make it a very good format for
> persistency.
Than
On Tue, Apr 26, 2016 at 6:40 AM, Tom Lane wrote:
> Craig Ringer writes:
>> On 26 April 2016 at 14:06, 陈天舟 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 t
Craig Ringer writes:
> On 26 April 2016 at 14:06, é天è 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)
On 04/26/2016 08:06 AM, 陈天舟 wrote:
I am interested in adding Protocol Buffer support for Postgres.
Protocol Buffer occupies less space than JSON. More importantly, it
has schema and is forward/backward compatible. All these make it a
very good format for persistency.
Have you investigated JSO
On 26 April 2016 at 14:06, 陈天舟 wrote:
> I am interested in adding Protocol Buffer support for Postgres. Protocol
> Buffer occupies less space than JSON. More importantly, it has schema and
> is forward/backward compatible. All these make it a very good format for
> persistency.
>
> Here are two r
I am interested in adding Protocol Buffer support for Postgres. Protocol
Buffer occupies less space than JSON. More importantly, it has schema and
is forward/backward compatible. All these make it a very good format for
persistency.
Here are two rough ideas I have right now:
Approach 1:
Creating
13 matches
Mail list logo
