Re: uuid type for postgres
От | mark@mark.mielke.cc |
---|---|
Тема | Re: uuid type for postgres |
Дата | |
Msg-id | 20050906144930.GA27641@mark.mielke.cc обсуждение исходный текст |
Ответ на | uuid type for postgres (nathan wagner <nw@hydaspes.if.org>) |
Ответы |
Re: uuid type for postgres
(Tom Lane <tgl@sss.pgh.pa.us>)
Re: uuid type for postgres (Josh Berkus <josh@agliodbs.com>) |
Список | pgsql-hackers |
Hey Nathan. I've started to make heavy use of pguuid. It had several bugs in it that required fixing before I could use it. I have no preference on pguuid. It was the only such PostgreSQL project I found that provided a UUID type. I'd be willing to work with you on ensuring that such a patch is in an acceptable form for the core developers to accept, and help maintain it. My personal preference is that the type be called 'uuid' and accepted into the core. Tom? Is their history on this issue? Should it remain an extension, or can be get it built-in? I find the UUID concept more useful than the SERIAL concept for data that must now, or may in the future, be stored on multiple servers. For example, submitting transactions to two different sites, where the sites periodically synchronize up with each other, requiring a relatively safe 'merge'. SERIAL can't do this at all. UUID can do this as long as the rows are split into domains appropriately, such as ensuring that unique column constraints do not need to be enforced across sites. UUID is also desirable over SERIAL for a unique identifier that will be accessed from an outside source directly. Exposing the SERIAL number to the outside isn't appealing for reasons including the predictability of the sequence, the size of the database is exposed, the internel implementation is exposed, and so on. I suggest that UUID be recommended in place of SERIAL for certain classes of applications, and that it therefore belongs in the core. UUID and SERIAL can be used together (although, once you have a UUID, it may not be useful to also have a SERIAL). Ok, you can all tell me I'm wrong now... :-) mark On Tue, Sep 06, 2005 at 01:50:57PM +0000, nathan wagner wrote: > > I have been in need of a uuid type and ran across the pguuid download > by Xiongjian (Mike) Wang. This wasn't really useful to me for two > reasons: first, it is GPLed and I would prefer a more liberal license, > secondly, it didn't compile cleanly on Mac OS 10.3, due to lack of a > SIOCGETIFHWADDR (? i think, i can get the exact name if you want it) > ioctl() under darwin. > > While I could dike out the code that calls it, that seems like a suboptimal > solution. So after a bit of poking around the interweb i ran across > Ralf Engelschall's ossp uuid library. This compiled with minimal > effort on mac os. Some reading, and an evening later, i've made > a server plugin with supporting SQL that implements an 'ossp_uuid' > type. > > Now i have four questions: > > 1: Is it feasible for this to be included in the contrib section of > the regular download? The uuid library is a "notice of copyright" style > license, and I am willing to put my own code into the public domain. > > 2: Would just calling the type 'uuid' be better than 'ossp_uuid'? It's > certainly a nicer name. > > 3: Would it be possible to include such a type as a postgres extension > to the usual SQL types. It seems to me that having an officially > supported type would be better than a user contributed type on the grounds > that you could then rely on it being avaiable if postgres was. > In particular, installing it as an extension would require the cooperation > of the DBA, which may be infeasible in some environments. > > -- > Nathan Wagner > -- mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bindthem... http://mark.mielke.cc/
В списке pgsql-hackers по дате отправления: