On Wed, Apr 23, 2014 at 12:24:21PM -0700, David Fetter wrote:
> On Wed, Apr 23, 2014 at 02:26:50PM -0300, Alvaro Herrera wrote:
> > Josh Berkus wrote:
> > > On 04/23/2014 07:43 AM, Alexander Korotkov wrote:
> > > > I can propose contrib PostgreNoSQL providing following:
> > > > 1) Table postgres as you proposed.
> > > > 2) Functions: get_postgres(id intgeger) returns jsonb, set_postgres(id
> > > > integer, data jsonb) returns void, search_postgres(query jsonb) returns
> > > > setof postgres. search_postgres will have semantics of @> jsonb operator
> > > > 3) Background workers which provides HTTP wrapper over those functions.
> > >
> > > You're forgetting ... sharding/replication over multiple masters.
> > >
> > > Also, the id should be a text value so that folks can use hash keys, or
> > > whatever.
> >
> > We should totally have a type "uuidserial".
>
> Something like it, certainly. One thing SQL Server does right is to
> have an opaque identity column, for which UUID would do an admirable
> job. We would need to build UUID functionality in, and I don't see
> this as a hard task. Should I draft it up as a self-contained
> extension?
So I did a little research, and it appears that there's a part of
util-linux that does UUIDs and is available under the 3-clause BSDL.
It only does time- and urandom-based UUIDs, but that's probably a
better start than nothing.
Is there any good reason not to roll native UUID generation into our
standard distribution?
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
