One reason to use a UUID type over a naively stored hash for this purpose is that it takes up half the space as naively stored MD5 and 40% of the space as naively stored SHA1. Granted, it's easy enough to pack them, but packed MD5 does have the same storage requirements as UUID and it won't be qui
>From what you said:
> I agreed this would work, and enhanced
> this by copying a trick from the SASL people where the key would be
> concatenated with a constant secret string to further prevent people
> from guessing how to crack the numbering scheme
under definition of security, "Something tha
On Thu, Sep 08, 2005 at 12:02:54PM -0400, Jonah H. Harris wrote:
> I think what Greg suggested was sha1(number) as the key instead of requiring
> uuid as the key... it would perform the same function as far as you r use
> case is concerned.
I'm sure he meant something like this. But I am still f
Mark,
I think what Greg suggested was sha1(number) as the key instead of
requiring uuid as the key... it would perform the same function as far
as you r use case is concerned.
As a similar example (using MD5):
CREATE SEQUENCE marks_seq START 1 INCREMENT 1;
CREATE TABLE your_tbl (
your_key
On Thu, Sep 08, 2005 at 01:45:10PM -, Greg Sabino Mullane wrote:
> > For a rather simple example, consider a site that associates a picture
> > with each member. If the pictures are named 1.jpg, 2.jpg, 3.jpg, etc.
> > it makes it ridiculously easy to write a script to pull all of the
> > pictur
Greg, thanks for saying it... I was thinking the same thing.
Not that it really relates to the UUID data type inclusion discussion
itself, but I think this application design and use case for UUID is an
example of using a data type for the wrong purpose. Application
design-wise, security should b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>> I'm also a little baffled to come up with any real application where making
>> an id number for most tables "unguessable" would provide any kind of real
>> protection not far better provided by other means. For your "users"
>> table, sure, but t
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> This is a fairly recent 8.1, maybe post-beta1. Not sure what happened.
This:
2005-05-07 01:48 neilc
* configure, configure.in: Revert the ld --as-needed patch. This
breaks Fedora Core 3, due to a strange interaction between ld,
On Wed, Sep 07, 2005 at 11:31:16AM -0700, Josh Berkus wrote:
> I'm also a little baffled to come up with any real application where making
> an id number for most tables "unguessable" would provide any kind of real
> protection not far better provided by other means. For your "users"
> table,
Alvaro Herrera wrote:
This is a fairly recent 8.1, maybe post-beta1. Not sure what happened.
I certainly don't see the --as-needed in LDFLAGS:
$ pg_config | grep LDFLA
LDFLAGS = -Wl,-rpath,/pg/install/00orig/lib
LDFLAGS_SL =
It was removed because it was very badly broken.
cheers
On Sep 7, 2005, at 10:04 AM, nathan wagner wrote:
On Wed, Sep 07, 2005 at 09:45:17AM -0700, josh@agliodbs.com wrote:
I think the issue is portability. Remember that this type needs
to work on
Windows as well as all POSIX platforms and AIX.
I had forgotten about windows. I'll see to wha
On Wed, Sep 07, 2005 at 06:48:41PM +0100, Patrick Welche wrote:
> On Wed, Sep 07, 2005 at 09:45:17AM -0700, Josh Berkus wrote:
> > > Nathan wrote:
> >
> > > Quite a list. I wonder what readline is doing there.
> >
> > Readline is for PSQL command completion and history. As for the rest, they
>
Nathan,
> http://granicus.if.org/~nw/uuid/
>
> Given the statement that it won't be accepted for contrib or core
> unless it compiles on windows, I guess I won't really have anything
> further to say on the topic. I don't have any way to compile on
> windows, so it's not an obstacle I can readily
Patrick Welche <[EMAIL PROTECTED]> writes:
> Still seems odd to me: I would expect psql to have readline, not postgres.
That's because we generate just one LIBS list and use it for all the
executables we build. Autoconf makes it a bit difficult to do
otherwise.
There is an option in the linux li
On Wed, Sep 07, 2005 at 06:35:51PM +, nathan wagner wrote:
> I have made a new version, and made a web page for it.
>
> http://granicus.if.org/~nw/uuid/
>
> Given the statement that it won't be accepted for contrib or core
> unless it compiles on windows, I guess I won't really have anything
nathan wagner <[EMAIL PROTECTED]> writes:
> On Wed, Sep 07, 2005 at 09:45:17AM -0700, josh@agliodbs.com wrote:
>> How does it generate its machine identifier?
> No idea. Does it matter? Not having to fret this kind of detail is
> the advantage of using someone else's library.
It absolutely matt
Josh Berkus writes:
> One of the differences between an add-in and core code is support for all
> PostgreSQL platforms.
These days, things won't get into contrib either if they don't work on
all the buildfarm machines.
regards, tom lane
---(end o
I have made a new version, and made a web page for it.
http://granicus.if.org/~nw/uuid/
Given the statement that it won't be accepted for contrib or core
unless it compiles on windows, I guess I won't really have anything
further to say on the topic. I don't have any way to compile on windows,
s
Nathan,
> I was thinking of cryptographic applications. Then, to use an
> example from another domain, initial TCP sequence numbers should
> be random (i.e. unguessable). A problem with TCP perhaps. It's
> been a while since i've read over my copy of _Applied Cryptography_,
> but I seem to reca
On Wed, Sep 07, 2005 at 09:48:08AM -0700, josh@agliodbs.com wrote:
> That's good, it gives users options. And I can see why you don't want to
> re-create the functionality in PG code, it's probably pretty large.
It would also be something else that would have to be maintained and
debugged. Whi
On Wed, Sep 07, 2005 at 09:45:17AM -0700, Josh Berkus wrote:
> > Nathan wrote:
>
> > Quite a list. I wonder what readline is doing there.
>
> Readline is for PSQL command completion and history. As for the rest, they
> are *optional* modules that apparently your RPM builder chose to include; I
On Wed, Sep 07, 2005 at 09:45:17AM -0700, josh@agliodbs.com wrote:
> I think the issue is portability. Remember that this type needs to work on
> Windows as well as all POSIX platforms and AIX.
I had forgotten about windows. I'll see to what extent the library i'm
using is portable to windows.
Nathan,
> > - linking against libuuid is fine for a contrib/ extension, but no
> > good for a built-in type. A real uuid would have to do a proper
> > independent implementation of uuid creation within pgsql.
>
> Why?
I think the issue is portability. Remember that this type needs to work on
W
Nathan,
> Take a look at the version 3 or version 5 UUIDs. They essentially do this.
> The hash isn't reversable, but rather recreatable. Seems that if it
> were reversable, it would be compression, not a hash. Anyway.
Hmmm, yes, true.
> You're assuming though that you want to leak this infor
# [EMAIL PROTECTED] / 2005-09-06 17:54:34 -0400:
> There's a fair amount of nearly
> unmaintained cruft in the core distro already (eg, the never-finished
> "line" datatype ... or the entire rtree index module ...) and a datatype
> that might be used by only a few people is a likely candidate to be
On Tue, Sep 06, 2005 at 08:40:08PM -0700, [EMAIL PROTECTED] wrote:
> - linking against libuuid is fine for a contrib/ extension, but no
> good for a built-in type. A real uuid would have to do a proper
> independent implementation of uuid creation within pgsql.
Why?
I'm not sure what the d
Paul Ramsey <[EMAIL PROTECTED]> writes:
> I am not sure if I heard clearly from the core team that a self-
> contained, BSD-licensed uuid would be accepted(able)?
I don't think any of the other core members weighed in on this thread,
so speaking strictly for myself: BSD license is an issue, and
p
Just an FYI:
We also ended up rolling our own uuid type, against libuuid. It
seems that uuid is a widespread enough concept that implementors
*will* be asked to support it, moderately often. We *could* roll our
own (were capable), others are not so lucky, and would have to point
out the
On Tue, Sep 06, 2005 at 06:40:27PM -0700, josh@agliodbs.com wrote:
> Sure. What's a UUID, after all? It's three pieces of information:
> 1) A server or database instance identifier
> 2) A table identifier
> 3) A row identifier
>
> e.g.:
> chayote.sf.agliodbs.com | public.customers | 4271
>
>
wagner
> Subject: Re: [HACKERS] uuid type for postgres
>
> Mark,
>
> > I agree. Although I lost it on the "cannot be normalized". I'm
assuming
> > there are designs you have seen much worse than the ones I have
seen.
> > :-)
>
> Mostly it's the prob
Mark,
> I agree. Although I lost it on the "cannot be normalized". I'm assuming
> there are designs you have seen much worse than the ones I have seen.
> :-)
Mostly it's the problem of tables that don't have a real key, only a
surrogate key. How do you know what's a duplicate?
> > For my part,
On Tue, Sep 06, 2005 at 06:02:50PM -0700, Josh Berkus wrote:
> However, Mark went on to suggest that we should recommend UUID over SERIAL
> in the docs, and that we could consider dropping SERIAL entirely in favor
> of UUID:
> ---quoth Mark--
> I suggest that UUID be recommended i
On Sep 6, 2005, at 6:02 PM, Josh Berkus wrote:
Bob, People,
Let me clarify my stance here, because it seems to be getting
misrepresented.
Mark (and Nathan) pushed at repaired UUID type for possible
inclusion in
the core PostgreSQL distribution. I'm not opposed to that,
provided that
the
Bob, People,
Let me clarify my stance here, because it seems to be getting
misrepresented.
Mark (and Nathan) pushed at repaired UUID type for possible inclusion in
the core PostgreSQL distribution. I'm not opposed to that, provided that
the portability, licensing, and bugs are worked out. Wh
[EMAIL PROTECTED] writes:
> Eventually, SERIAL wraps around. So you switch to SERIAL8. At the point that
> you have SERIAL8, you aren't worried terribly about disk space, and you
> realize there is usually no benefit at all to the numbers being ordered so
> closely.
a) Except for trivially small
Tom, you worded my thoughts much better than I did.
Bob, I too had heard that host-based UUIDs/GUIDs had issues with
uniqueness. I think Microsoft's implementation was hosed and they
ended up eliminating using the MAC completely.
I'll check out the code & get back.
On 9/6/05, Bob Ippolito <[EMAI
On Sep 6, 2005, at 3:06 PM, [EMAIL PROTECTED] wrote:
On Tue, Sep 06, 2005 at 05:54:34PM -0400, Tom Lane wrote:
I don't see any "big opposition". People are simply questioning the
idea whether it belongs in core PG. The reason we don't want to
accept
everything-and-the-kitchen-sink in cor
On Tue, Sep 06, 2005 at 05:54:34PM -0400, [EMAIL PROTECTED] wrote:
> One thing that is raising my own level of concern quite a bit is the
> apparent portability issues.
I can't speak to the portability in general, but there is a PORTING file
in the ossp uuid library that states
OSSP uuid was al
As promised a link to the code.
http://granicus.if.org/~nw/ossp_pg_uuid-0.1.tar.gz
You'll also need Ralf Engelschall's uuid library, which mine is a postgres
interface to. It's available at
ftp://ftp.ossp.org/pkg/lib/uuid/uuid-1.3.0.tar.gz
It probably has a few warts. I'm mainly posting it fo
On Tue, Sep 06, 2005 at 05:54:34PM -0400, Tom Lane wrote:
> I don't see any "big opposition". People are simply questioning the
> idea whether it belongs in core PG. The reason we don't want to accept
> everything-and-the-kitchen-sink in core is that we have only limited
> manpower to maintain it
On Tue, Sep 06, 2005 at 05:31:43PM -0400, Greg Stark wrote:
> Just do something like this for every sequence:
> ALTER SEQUENCE foo INCREMENT BY 100
> And then choose a particular initial value for each server.
*shudder*
But you are right. That would work. :-) (I shudder from the maintenance
he
[EMAIL PROTECTED] writes:
> Personally, I'm not sure what the big opposition to UUID is all about.
I don't see any "big opposition". People are simply questioning the
idea whether it belongs in core PG. The reason we don't want to accept
everything-and-the-kitchen-sink in core is that we have on
[EMAIL PROTECTED] writes:
> In my choice of use, I'm using them instead of SERIAL columns, as I
> wish to have more freedom merging production data with test data. I
> wish to continually import production data into my test environment,
> in a single direction. UUID will prevent conflicts from o
On Tue, Sep 06, 2005 at 01:49:28PM -0700, David Fetter wrote:
> On Tue, Sep 06, 2005 at 09:16:13PM +, nathan wagner wrote:
> > On Tue, Sep 06, 2005 at 03:57:55PM -0400, [EMAIL PROTECTED] wrote:
> > > I agree with Josh on the UUID type, it gets abused far too often
> > Out of curiosity, how does
On Sep 6, 2005, at 2:16 PM, nathan wagner wrote:
On Tue, Sep 06, 2005 at 03:57:55PM -0400, [EMAIL PROTECTED]
wrote:
I agree with Josh on the UUID type, it gets abused far too often
Out of curiosity, how does it get abused? It doesn't seem to me
that it would be any more prone to abuse t
On Tue, Sep 06, 2005 at 09:16:13PM +, nathan wagner wrote:
> On Tue, Sep 06, 2005 at 03:57:55PM -0400, [EMAIL PROTECTED] wrote:
> > I agree with Josh on the UUID type, it gets abused far too often
>
> Out of curiosity, how does it get abused? It doesn't seem to me
> that it would be any more
On Tue, Sep 06, 2005 at 03:57:55PM -0400, Jonah H. Harris wrote:
> I agree with Josh on the UUID type, it gets abused far too often and (IMHO)
> isn't widely enough used to belong in the core.
There is much in PostgreSQL from my perspective that falls under the
category of 'most advanced open sou
The only time I've seen someone use UUIDs in PostgreSQL is when they
were converting from SQL Server. I've seen many bad data models
using UUID that could've/should've used normal sequences for
portability.
I look forward to seeing you're code.
Thanks!
On 9/6/05, nathan wagner <[EMAIL PROTECTED]
On Sep 6, 2005, at 12:57 PM, Jonah H. Harris wrote:On 9/6/05, Josh Berkus wrote: Mark,> 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 yo
On Tue, Sep 06, 2005 at 03:57:55PM -0400, [EMAIL PROTECTED] wrote:
> I agree with Josh on the UUID type, it gets abused far too often
Out of curiosity, how does it get abused? It doesn't seem to me
that it would be any more prone to abuse than any other type.
> and (IMHO) isn't widely enough use
I agree with Josh on the UUID type, it gets abused far too often and
(IMHO) isn't widely enough used to belong in the core. Couldn't you just fix the problem in
pguuid rather than write a whole new type?On 9/6/05, Josh Berkus wrote:
Mark,> I suggest that UUID be recommended in
Mark,
> 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).
I think that, if you want to push
On Tue, Sep 06, 2005 at 11:38:57AM -0400, [EMAIL PROTECTED] wrote:
>
> There is pretty much zero chance of being accepted into contrib, much
> less core, if the code isn't pure BSD license.
Hmm. Here is the copyright and license portion of the readme...
COPYRIGHT AND LICENSE
Copyright (c)
[EMAIL PROTECTED] writes:
> 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?
There is pretty much zero chance of being accepted into contrib, much
less core, if th
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 i
--- Begin Message ---
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
56 matches
Mail list logo