-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 that's a
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
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
pictures off
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 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
>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 that
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
# [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 become
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
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
Windows
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.
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: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.
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 recall
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,
Josh Berkus josh@agliodbs.com 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
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 matters,
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
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
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
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
are
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
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 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, sure,
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,
---BeginMessage---
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
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
[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 the
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)
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 a
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 josh@agliodbs.com wrote:
Mark, I suggest that UUID be recommended in
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 used
On Sep 6, 2005, at 12:57 PM, Jonah H. Harris wrote:On 9/6/05, Josh Berkus josh@agliodbs.com 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 you
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 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
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 prone
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
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 it get
[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
[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 only
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
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. So
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
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
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 core
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 [EMAIL
[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
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.
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
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 in
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, I
-Original Message-
From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
[EMAIL PROTECTED] On Behalf Of Josh Berkus
Sent: Tuesday, September 06, 2005 6:40 PM
To: [EMAIL PROTECTED]
Cc: Bob Ippolito; [EMAIL PROTECTED];
pgsql-hackers@postgresql.org;
nathan wagner
Subject: Re: [HACKERS] uuid
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
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
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
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
56 matches
Mail list logo
