Re: GSoC proposal

From: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
To: "tankimtran(at)gmail(dot)com" <tankimtran(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GSoC proposal
Date: 2014-03-03 10:37:55
Message-ID: A737B7A37273E048B164557ADEF4A58B17CCE248@ntex2010i.host.magwien.gv.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> I'm applying for GSoC 2014 with Postgresql and would appreciate your comments on my proposal
> (attached). I'm looking for technical corrections/comments and your opinions on the project's
> viability. In particular, if the community has doubts about its usefulness, I would start working on
> an extra proposal from https://wiki.postgresql.org/wiki/GSoC_2014, perhaps on the RETURNING clause as
> a student named Karlik did last year.

I am sure that Simon had his reasons when he proposed
http://www.postgresql.org/message-id/CA+U5nMJGgJNt5VXqkR=crtDqXFmuyzwEF23-fD5NuSns+6N5dA@mail.gmail.com
but I cannot help asking some questions:

1) Why limit the feature to UTF8 strings?
Shouldn't the technique work for all multibyte server encodings?

2) There is probably something that makes this necessary, but why should the decision
how toast is sliced be attached to the data type?
My (probably naive) idea would be to add a new TOAST strategy (e.g. SLICED)
to PLAIN, MAIN, EXTERNAL and EXTENDED.

The feature only makes sense for string data types, right?

Yours,
Laurenz Albe

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message KONDO Mitsumasa 2014-03-03 10:50:41 Re: gaussian distribution pgbench
Previous Message Andres Freund 2014-03-03 10:16:40 Re: Patch: show relation and tuple infos of a lock to acquire