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 <da...@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
