Hi Adam,
On 06/17/2016 03:01 PM, Adam Brusselback wrote:
Just wondering what others have done for using enum or uuid columns in
exclusion constraints?
[snip]
And as a closing note on this, I really can't wait until these are
supported types for gist indexes.
Here is some work I did to add supp
This I got, need some implicit way, like maybe in RULE on SELECT can we
write this ?
Thanks
Sridhar
OpenText
On Mon, May 30, 2016 at 1:05 PM, Michael Paquier
wrote:
> On Mon, May 30, 2016 at 4:25 PM, Sridhar N Bamandlapally
> wrote:
> > Hi
> >
> > Is there a way to implicit SELECT on UUID data
On Mon, May 30, 2016 at 4:25 PM, Sridhar N Bamandlapally
wrote:
> Hi
>
> Is there a way to implicit SELECT on UUID datatype in uppercase ?
You could always cast an UUID back to text and use that with upper(),
though you are not explaining what you are tying to achieve:
=# select upper(gen_random_
On Tue, 22 Dec 2015 11:07:30 -0600
Brendan McCollam wrote:
> (previously posted to the pgsql-performance list)
>
> Hello,
>
> We're in the process of designing the database for a new service, and
> some of our tables are going to be using UUID primary key columns.
>
> We're trying to decide b
This affirmation that it indeed does work set me straight. I inadvertently made
a previously immutable UUID function volatile; it was providing the UUIDs in
the query.
> On Nov 9, 2014, at 2:12 PM, Tom Lane wrote:
>
> Kevin Wooten writes:
>> I am assuming I am crazy and missing something comp
Kevin Wooten writes:
> I am assuming I am crazy and missing something completely obvious but I
> cannot get postgres (9.3.5) to use an index on a UUID, ever.
Worksforme:
regression=# create table foo (f1 uuid primary key);
CREATE TABLE
regression=# explain select * from foo where f1 =
'a0eebc
On 11/09/2014 10:58 AM, Kevin Wooten wrote:
I am assuming I am crazy and missing something completely obvious but I cannot
get postgres (9.3.5) to use an index on a UUID, ever.
The main table has a natural composite key (2 uuids and a timestamp) with which
it always uses the timestamp as the i
Yeah, although cheap contribution by me.:-)
Thanks!
(2011/06/25 2:10), Michael Gould wrote:
> Thanks for the reply. We're using Windows 32 of Postgres in
development but
> would like to deploy windows 64 when we are ready. I agree, I think that
> Postgres ought to provide fully support for GU
Hi Michael-san.
Sorry very late reaction.
Although it is several years ago, I did the work origin of OSSP-UUID on
windows platform with Ralf-san. He is Great developer!.
http://www.ossp.org/pkg/lib/uuid/
However, I made the mistake in patch then
After late, correction patch was made this.
Thanks for the suggestion of casting the hex string to uuid. That works.
I tried the standard syntax using "CAST":
VALUES ( CAST( $1 AS uuid) )
--Basil Bourque
> How about:
> CREATE OR REPLACE FUNCTION public.uuid_write_(character varying)
> RETURNS boolean
> LANGUAGE plpgsql
> AS $function$
>
On Thursday, April 14, 2011 6:43:21 pm Basil Bourque wrote:
> If I pass the hex string representation of a UUID to a PL/pgSQL function as
> a varchar, that value cannot be used directly when writing to a row whose
> column data type is "uuid", in Postgres 9.0.x. Normally Postgres
> automatically co
Whoops… Typo in the Subject line. Should have been "UUID cannot" rather than
"UUID can".
UUID cannot be written to row when passed as parameter/argument to a PL/pgSQL
function. Feature or bug?
^^^
--Basil Bourque
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To
On 2011-01-06, Chris Browne wrote:
> (Sequence + Host Data), and I'd expect there to
> be a considerable risk of Dumb Techs making mistakes there. It wouldn't
> be difficult for such a scenario to induce systematic key collisions.
I've seen that happen. cleanup of the effected records was trick
On 6 Jan 2011, at 20:36, Chris Browne wrote:
> Infinite? The probability can't conceivably exceed 1.
Don't start picking om words please, "infinitely small" or "infinitesimal" is
obviously what I meant to write there.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees
Hey guys and gals,
As the originator of this topic, I've received a lot of good answers,
opinions, and advice. Thank you.
I'm not sure that more conversation on this will go anywhere but down. It
seems that UUID vs. Integer is one of those 'values' subjects, like:
Sexual practices a
On Jan 6, 2011, at 3:52 AM, Stuart Bishop wrote:
> Maybe I should start a business in providing UUID collision insurance?
Your ideas are intriguing to me and I wish to subscribe to your newsletter.
-M
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
In response to Chris Browne :
>
> It seems to me that using serially assigned values, along with manually
> assigned server IDs, to construct a would-be-unique value, is likely to
> introduce quite a lot *more risk* of system failure than would the use
> of UUIDs.
First off, server IDs are not ra
dal...@solfertje.student.utwente.nl (Alban Hertroys) writes:
> On 6 Jan 2011, at 17:51, Chris Browne wrote:
>
>> wmo...@potentialtech.com (Bill Moran) writes:
>> If your system is sufficiently negligently designed that this particular
>> conflict causes it to kill people, then I wouldn't be too inc
On 6 Jan 2011, at 17:51, Chris Browne wrote:
> wmo...@potentialtech.com (Bill Moran) writes:
> If your system is sufficiently negligently designed that this particular
> conflict causes it to kill people, then I wouldn't be too inclined to
> point at this issue with UUIDs being the Real Problem wi
On Jan 6, 2011, at 9:31 AM, Chris Browne wrote:
> The reasonable choices for a would-be artificial primary key seem to be
> 1 and 3; in a distributed system, I'd expect to prefer 1, as the time +
> host data are likely to eliminate the "oh, it might just randomly match"
> problem.
In some context
dennis.jenkins...@gmail.com (dennis jenkins) writes:
> The UUID itself is 128 bits. Some of those bits are pre-determined.
> I don't recall, but I think that a "normal" UUID has 121 bits of
> randomness.
That doesn't match RFC 4122 very well...
It indicates 5 forms of UUIDs:
1) Time-based, wher
wmo...@potentialtech.com (Bill Moran) writes:
> If the chance of a duplicate is 1 in a hundred gazillion, then I can
> still hit a dupe the VERY FIRST TIME I USE IT.
>
> I'm writing software that is intended to be used to save lives in the
> event of an earthquake or flood or cosmic ray flipping bi
On Wed, Jan 5, 2011 at 3:43 PM, Bill Moran wrote:
> Despite the fact that the chance of a collision is very, very small, there
> is no easy way to fix it if it happens. Zero. It can't be done without
> shutting the system down, recalling all the remote devices and manually
> reconciling the prob
On Jan 6, 2011, at 8:19 AM, Michael Satterwhite wrote:
> That would be a matter of incompetent administration. *NOTHING* can protect
> against that.
Well, no, not necessarily. It might well be a goal (in fact, is a goal with
some software that I'm developing), that users/admins don't have to wo
On Thursday 06 January 2011 7:14:00 am Bill Moran wrote:
> In response to Scott Ribe :
> > On Jan 6, 2011, at 1:52 AM, Stuart Bishop wrote:
> > > If you are looking at these extreme
> > > improbabilities, your SERIAL isn't guaranteed unique either when you
> > > take into account cosmic rays flippi
On Jan 6, 2011, at 8:14 AM, Bill Moran wrote:
> I don't give a fuck how small the chance of conflict is, the only
> viable option for that chance is 0. Period. Any argument to the
> contrary is stupid, asinine and outright negligent.
Do you give a fuck about the chance that bits will flip in th
In response to Scott Ribe :
> On Jan 6, 2011, at 1:52 AM, Stuart Bishop wrote:
>
> > If you are looking at these extreme
> > improbabilities, your SERIAL isn't guaranteed unique either when you
> > take into account cosmic rays flipping the right bits in your ECC
> > memory or on your disk platte
On Jan 6, 2011, at 1:52 AM, Stuart Bishop wrote:
> If you are looking at these extreme
> improbabilities, your SERIAL isn't guaranteed unique either when you
> take into account cosmic rays flipping the right bits in your ECC
> memory or on your disk platter.
Yes, that's rather the point, the pro
On Jan 6, 2011, at 2:51 AM, Jasen Betts wrote:
> Who was it that decided on 32 bits for IP addresses?
Nice try, but that was rather long before the IETF existed ;-)
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice
--
Sent via pgsql-general mailin
On 2011-01-05, Scott Ribe wrote:
> On Jan 5, 2011, at 9:01 AM, Tom Lane wrote:
>
>> In practical use I think the odds of a collision are *far* higher than
>> you are suggesting, unless the UUID generation is being done with a lot
>> more care than is likely if the user takes these sorts of claims
>>> Next to that, UUID's are generated by computers. I have no doubts that
>>> the numeric space that makes up a UUID allows for collision chances as
>>> low as described, but are computers capable of generating those
>>> numbers sufficiently random that they actually achieve that low a
>>> chance?
On 6 Jan 2011, at 24:27, Chris Browne wrote:
>> Next to that, UUID's are generated by computers. I have no doubts that
>> the numeric space that makes up a UUID allows for collision chances as
>> low as described, but are computers capable of generating those
>> numbers sufficiently random that th
On Wed, Jan 05, 2011 at 07:46:18PM -0700, Scott Ribe wrote:
> And if somebody clones the disk to a new machine, but leaves the old one in
> service? Or do you use the MAC address and hope that's unique?
>
Excellent questions, and exactly the sort (as I was arguing elsewhere
in this thread) one h
On Wed, Jan 05, 2011 at 07:44:29PM -0700, Scott Ribe wrote:
> In order for a collision to matter, really in order for there to *be* a
> collision, the duplicate pair has to be collected in one place.
Not at the time of generation, though. They only have to end up in
the same place at once. Fo
On Wed, Jan 05, 2011 at 06:22:08PM -0500, Chris Browne wrote:
> But it seems to me that some of the analytics are getting a little *too*
> paranoid, on the "perhaps UUIDs are the wrong answer" side of the
> column.
That could be. I was simply noting that there are cases where one
could legitimate
On Jan 5, 2011, at 4:11 PM, Michael Satterwhite wrote:
> Each machine would have a unique machine_id. This would guarantee uniqueness
> and be very easy to maintain.
And if somebody clones the disk to a new machine, but leaves the old one in
service? Or do you use the MAC address and hope that'
On Jan 5, 2011, at 3:03 PM, Andrew Sullivan wrote:
> ...the example was not that UUIDs are being generated and collected
> in one place at that rate, but that they're being generated in several
> independent places at a time...
In order for a collision to matter, really in order for there to *be*
a...@crankycanuck.ca (Andrew Sullivan) writes:
> On Wed, Jan 05, 2011 at 12:41:43PM -0700, Scott Ribe wrote:
>> I'm not sidestepping the point at all.
>
> You may be missing it, however, because. . .
>
>> The point is that the finiteness of the space is a red herring. The
>> space is large enough t
dal...@solfertje.student.utwente.nl (Alban Hertroys) writes:
>>> From wikipedia, "only after generating 1 billion UUIDs every second for
>> the next 100 years, the probability of creating just one duplicate would
>> be about 50%. The probability of one duplicate would be about 50% if
>> every perso
On 6 January 2011 00:32, dennis jenkins wrote:
> On Wed, Jan 5, 2011 at 1:03 PM, Bill Moran
> wrote:
> >
> > But the point (that you are trying to sidestep) is that the UUID
> namespace
> > is finite, so therefore you WILL hit a problem with conflicts at some
> point.
> > Just because that point
Pooled id.. child machine connects to main and says give 1 of ids,
main increments counter by 1, child allocates in given pool.
On Wed, 5 Jan 2011 17:11:35 -0600, Michael Satterwhite
wrote:
Once multiple machines are linked to maintain the database, this has
a flaw in
it as a series i
On Wed, Jan 5, 2011 at 1:03 PM, Bill Moran wrote:
>
> But the point (that you are trying to sidestep) is that the UUID namespace
> is finite, so therefore you WILL hit a problem with conflicts at some point.
> Just because that point is larger than most people have to concern themselves
> with isn
On 01/05/2011 03:39 PM, Alban Hertroys wrote:
>>> From wikipedia, "only after generating 1 billion UUIDs every second for
>> the next 100 years, the probability of creating just one duplicate would
>> be about 50%. The probability of one duplicate would be about 50% if
>> every person on earth ow
>> From wikipedia, "only after generating 1 billion UUIDs every second for
> the next 100 years, the probability of creating just one duplicate would
> be about 50%. The probability of one duplicate would be about 50% if
> every person on earth owns 600 million UUIDs."
Even if the chances of one
On Wed, Jan 05, 2011 at 12:41:43PM -0700, Scott Ribe wrote:
> I'm not sidestepping the point at all.
You may be missing it, however, because. . .
> The point is that the finiteness of the space is a red herring. The
> space is large enough that there's no chance of collision in any
> realistic sc
On 01/05/2011 01:43 PM, Bill Moran wrote:
> In response to Rob Sargent :
>>>
>>> In our case (and I expect it's the case with most people considering UUIDs)
>>> we're talking about independent devices that occasionally synchronize
>>> data between themselves. These devices need to generate a uni
In response to Rob Sargent :
> >
> > In our case (and I expect it's the case with most people considering UUIDs)
> > we're talking about independent devices that occasionally synchronize
> > data between themselves. These devices need to generate a unique ID
> > of some sort without having to che
On 05/01/2011 19:41, Scott Ribe wrote:
to every atom in the observable universe, or 10^51 UUIDs to every
atom in the total universe using high-end estimates of the size of
the non-observable universe)?
Is that taking dark matter into account? :-)
Ray.
--
Raymond O'Donnell :: Galway :: Ireland
On Jan 5, 2011, at 1:13 PM, Raymond O'Donnell wrote:
> Is that taking dark matter into account? :-)
It's not clear to me ;-)
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To
On 01/05/2011 11:57 AM, Bill Moran wrote:
> In response to Rob Sargent :
>
>>
>>
>> On 01/05/2011 08:55 AM, Bill Moran wrote:
>>> In response to Scott Ribe :
>>>
On Jan 5, 2011, at 8:05 AM, Bill Moran wrote:
> Beyond that, the namespace size for a UUID is so incomprehensibly huge
>
On Jan 5, 2011, at 12:03 PM, Bill Moran wrote:
> For crying out loud. If you're going to pick me apart with numbers, then
> actually do it with some intelligence.
If you're going to get nasty, at least try to be accurate.
> I could easily counter your argument by upping the numbers to 500,000
>
postgresql.org
Sent: Wed, January 5, 2011 2:50:11 AM
Subject: Re: [GENERAL] UUID column as pimrary key?
On 01/05/2011 07:31 PM, Radosław Smogura wrote:
> * you have your id, before executing query, (in contrast to all this
> autoincrement) so you may put it in dependant rows
Do you mean that
On Jan 5, 2011, at 11:31 AM, Radosław Smogura wrote:
> The true is that probability
> that in two coin drops we will get two reverses is 1/4, but true is, too, as
> Newton said, it's 1/3, because if in 1st drop we don't get reverse we don't
> need to drop again.
Nonsense. You don't stop genera
In response to Scott Ribe :
> On Jan 5, 2011, at 8:55 AM, Bill Moran wrote:
>
> > That statement demonstrates a lack of investigation and/or consideration
> > of the circumstances.
>
> No, it doesn't.
>
> > However, if there are 5000 devices generating 100 UUIDs per hour, and you'll
> > be keep
In response to Rob Sargent :
>
>
> On 01/05/2011 08:55 AM, Bill Moran wrote:
> > In response to Scott Ribe :
> >
> >> On Jan 5, 2011, at 8:05 AM, Bill Moran wrote:
> >>
> >>> Beyond that, the namespace size for a UUID is so incomprehensibly huge
> >>> that the chance of two randomly generated U
Scott Ribe Wednesday 05 January 2011 17:33:51
> On Jan 5, 2011, at 9:19 AM, Leif Biberg Kristensen wrote:
> > I can't help thinking of the «Birthday Paradox»:
> Yes, the calculation of the probability of a collision is the same for the
> "birthday paradox" as for random UUID collisions.
Depends o
On Jan 5, 2011, at 10:30 AM, Radosław Smogura wrote:
> 128bits is huge for now, but what will happen in next 2,3 years?
It will still be large. When you get up to around 100 trillion UUIDs, you'll be
getting up to around a 1 in a billion chance of a single collision. Before you
claim that we'll
Original Message
Subject: Re: [GENERAL] UUID column as pimrary key?
Date: Wed, 5 Jan 2011 10:11:49 -0700
From: Scott Ribe
To: Adrian Klaver
On Jan 5, 2011, at 9:57 AM, Adrian Klaver wrote:
Maybe or maybe not:)
So... If you choose to use a name-based UUID, *and* you do a
Sorry for not citation...
When I was talking about "almost unique", I was meaning that the UUID is
random so there is no guarantee that you will not generate two indencital
UUIDs even in subsequent calls, but it has low probability (you have
greater chances to win in LOTTO).
128bits is hug
On 01/05/2011 08:29 AM, Scott Ribe wrote:
On Jan 5, 2011, at 9:01 AM, Tom Lane wrote:
In practical use I think the odds of a collision are *far* higher than
you are suggesting, unless the UUID generation is being done with a lot
more care than is likely if the user takes these sorts of claims a
On Wed, Jan 5, 2011 at 3:03 PM, Mike Christensen wrote:
> 2011/1/5 Grzegorz Jaśkiewicz :
>> On Wed, Jan 5, 2011 at 2:37 PM, Scott Ribe
>> wrote:
>>> On Jan 5, 2011, at 1:31 AM, Radosław Smogura wrote:
>>>
* simple to generate, and 128bit random is almost globally unique,
>>>
>>> Almost? Sho
On Jan 5, 2011, at 9:19 AM, Leif Biberg Kristensen wrote:
> I can't help thinking of the «Birthday Paradox»:
Yes, the calculation of the probability of a collision is the same for the
"birthday paradox" as for random UUID collisions.
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevate
On Jan 5, 2011, at 9:01 AM, Tom Lane wrote:
> In practical use I think the odds of a collision are *far* higher than
> you are suggesting, unless the UUID generation is being done with a lot
> more care than is likely if the user takes these sorts of claims at face
> value.
Eh? The user taking su
On Wednesday 5. January 2011 16.05.29 Bill Moran wrote:
> Beyond that, the namespace size for a UUID is so incomprehensibly huge
> that the chance of two randomly generated UUIDs having the same value
> is incomprehensibly unlikely ... it is, however, not a 100% guarantee.
I can't help thinking
On Jan 5, 2011, at 8:55 AM, Bill Moran wrote:
> That statement demonstrates a lack of investigation and/or consideration
> of the circumstances.
No, it doesn't.
> However, if there are 5000 devices generating 100 UUIDs per hour, and you'll
> be keeping those records for 10+ years, the chances of
On 01/05/2011 08:55 AM, Bill Moran wrote:
> In response to Scott Ribe :
>
>> On Jan 5, 2011, at 8:05 AM, Bill Moran wrote:
>>
>>> Beyond that, the namespace size for a UUID is so incomprehensibly huge
>>> that the chance of two randomly generated UUIDs having the same value
>>> is incomprehensib
Scott Ribe writes:
> On Jan 5, 2011, at 8:05 AM, Bill Moran wrote:
>> Beyond that, the namespace size for a UUID is so incomprehensibly huge
>> that the chance of two randomly generated UUIDs having the same value
>> is incomprehensibly unlikely
> Yes, as in: it is *far* more likely that all of y
In response to Scott Ribe :
> On Jan 5, 2011, at 8:05 AM, Bill Moran wrote:
>
> > Beyond that, the namespace size for a UUID is so incomprehensibly huge
> > that the chance of two randomly generated UUIDs having the same value
> > is incomprehensibly unlikely
>
> Yes, as in: it is *far* more lik
On Jan 5, 2011, at 8:05 AM, Bill Moran wrote:
> Beyond that, the namespace size for a UUID is so incomprehensibly huge
> that the chance of two randomly generated UUIDs having the same value
> is incomprehensibly unlikely
Yes, as in: it is *far* more likely that all of your team members and all o
On Jan 5, 2011, at 8:03 AM, Mike Christensen wrote:
> As long as all your UUIDs are generated with the same algorithm, they
> are guaranteed to be unique.
There is no requirement that they be generated with the same algorithm in order
to be unique. A MAC/time-based UUID cannot duplicate a random
In response to Scott Ribe :
> On Jan 5, 2011, at 1:31 AM, Radosław Smogura wrote:
>
> > * simple to generate, and 128bit random is almost globally unique,
>
> Almost? Should be totally unique, as long as your random source is decent
> quality.
This is going off-topic, but I did some research o
On Jan 5, 2011, at 7:55 AM, Grzegorz Jaśkiewicz wrote:
> But I would never rely on that alone. You always have a strategy in
> place, in case there's a duplicate.
That's really unnecessary, basically a total waste of effort.
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
2011/1/5 Grzegorz Jaśkiewicz :
> On Wed, Jan 5, 2011 at 2:37 PM, Scott Ribe
> wrote:
>> On Jan 5, 2011, at 1:31 AM, Radosław Smogura wrote:
>>
>>> * simple to generate, and 128bit random is almost globally unique,
>>
>> Almost? Should be totally unique, as long as your random source is decent
>>
On Wed, Jan 5, 2011 at 2:37 PM, Scott Ribe wrote:
> On Jan 5, 2011, at 1:31 AM, Radosław Smogura wrote:
>
>> * simple to generate, and 128bit random is almost globally unique,
>
> Almost? Should be totally unique, as long as your random source is decent
> quality.
But I would never rely on that
On Jan 5, 2011, at 7:28 AM, Radosław Smogura wrote:
> It's simpler to write:
...
> isn't it?
Depends on the situation, the libraries you're using, and so on.
Now, if you're generating records in a distributed system, where your node
might be disconnected when it's creating a record, it is *much
On Jan 5, 2011, at 1:31 AM, Radosław Smogura wrote:
> * simple to generate, and 128bit random is almost globally unique,
Almost? Should be totally unique, as long as your random source is decent
quality.
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voic
On 5 January 2011 15:28, Radosław Smogura wrote:
> On Wed, 05 Jan 2011 21:50:11 +1100, Craig Ringer <
> cr...@postnewspapers.com.au> wrote:
>
>> On 01/05/2011 07:31 PM, Radosław Smogura wrote:
>>
>> * you have your id, before executing query, (in contrast to all this
>>> autoincrement) so you ma
On Wed, 05 Jan 2011 21:50:11 +1100, Craig Ringer
wrote:
On 01/05/2011 07:31 PM, Radosław Smogura wrote:
* you have your id, before executing query, (in contrast to all this
autoincrement) so you may put it in dependant rows
Do you mean that with a UUID, you don't need to talk to the database
On 01/05/2011 07:31 PM, Radosław Smogura wrote:
* you have your id, before executing query, (in contrast to all this
autoincrement) so you may put it in dependant rows
Do you mean that with a UUID, you don't need to talk to the database at
all, you can generate an ID with no interaction with
On Tue, 4 Jan 2011 11:07:00 -0800 (PST), Dennis Gearon
wrote:
I haven't been able to find anywhere, easily, in the documentation
using google
where a list of allowed data types for primary keys is.
So, UUIDs can be primary keys?
Any issues wtih them on sorting or paging of index tables, etc.?
d.w...@computer.org (David Wall) writes:
> We're using UUID for primary keys in PG 8.4 without any issues. I
> have no real insights into the details or performance issues, but
> always figured it was stored as a binary 128-bit value, but with added
> benefits of being able to enter and view them
We're using UUID for primary keys in PG 8.4 without any issues. I have
no real insights into the details or performance issues, but always
figured it was stored as a binary 128-bit value, but with added benefits
of being able to enter and view them using a standard string format. We
don't sor
On Tue, 2011-01-04 at 11:07 -0800, Dennis Gearon wrote:
> I haven't been able to find anywhere, easily, in the documentation using
> google
> where a list of allowed data types for primary keys is.
Anything that can be UNIQUE NOT NULL
>
> So, UUIDs can be primary keys?
Yes.
JD
--
PostgreS
yourself.
from 'http://blogs.techrepublic.com.com/security/?p=4501&tag=nl.e036'
EARTH has a Right To Life,
otherwise we all die.
- Original Message
From: bricklen
To: Dennis Gearon
Sent: Sun, January 2, 2011 8:49:13 PM
Subject: Re: [GENERAL] uuid, COMB uuid, distributed
One of the issues with using UUIDs for primary keys, or even in a secondary key
using a unique index,would be paging of the index because of the randomness of
the values. This is what I have read, is that true for Posgres?
On the tests in this article, doing large amounts of consecutive inserts,
On Thu, 2010-06-17 at 20:56 -0400, Ozz Nixon wrote:
> I found a page:
>
> http://www.postgresql.org/docs/8.3/static/uuid-ossp.html
>
> Is that the only way to get UUID from postgresql?
>
> * We are in the midst of porting a replication product to support postgresql,
> which relies on UUID
Thanks, that worked perfectly.
Best Regards
Michael Gould
"Sachin Srivastava" wrote:
>Hello Michael,
>
>In the EnterpriseDB installer, uuid-ossp contrib module is available but
>not loaded/enabled by default. To enable uuid-ossp module simply run the
>uuid-ossp.sql file ("share\cont
Hello Michael,
In the EnterpriseDB installer, uuid-ossp contrib module is available but
not loaded/enabled by default. To enable uuid-ossp module simply run the
uuid-ossp.sql file ("share\contrib\uuid-ossp.sql").
This is something that i did:
psql.exe -U postgres -d postgres -f share\contrib
Tom Lane wrote:
> (I believe that 8.3 takes braces too ... but it's pickier about where
> it allows dashes.)
This is what the 8.3 comment says:
/*
* We allow UUIDs in three input formats: 8x-4x-4x-4x-12x,
* {8x-4x-4x-4x-12x}, and 32x, where "nx" means n hexadecimal digits
* (only the first fo
On Mon, Jul 13, 2009 at 03:28:09PM -0400, Tom Lane wrote:
- David Kerr writes:
- > Tried w/o escaping:
- > insert into testuuid values ('{a0eebc99-9c0b4ef8-bb6d6bb9-bd380a11}');
- > ERROR: invalid input syntax for uuid:
"{a0eebc99-9c0b4ef8-bb6d6bb9-bd380a11}"
-
- Works for me:
-
- regression=#
David Kerr writes:
> Tried w/o escaping:
> insert into testuuid values ('{a0eebc99-9c0b4ef8-bb6d6bb9-bd380a11}');
> ERROR: invalid input syntax for uuid: "{a0eebc99-9c0b4ef8-bb6d6bb9-bd380a11}"
Works for me:
regression=# select '{a0eebc99-9c0b4ef8-bb6d6bb9-bd380a11}'::uuid;
uui
Go figure, eh? It wasn't there when I installed the RHEL version. But
its all good.
Chris
On Sat, 2009-04-04 at 22:28 +0300, Devrim GÜNDÜZ wrote:
> On Sat, 2009-04-04 at 11:36 -0500, Chris spotts wrote:
> > Well, the only file that shows up is the uninstall file? Thats a
> > little odd.
>
> I s
On Sat, 2009-04-04 at 13:03 -0700, David Kerr wrote:
> FWIW it's not in contrib on SLES 11 or on opensuse 11 for 8.3
I am about to announce OpenSuSE 11+ and SLES 10+ RPMs soon, really soon,
which will include all features that PGDG Fedora/RH/CentOS RPMs have. If
you are not in a hurry, you may wai
FWIW it's not in contrib on SLES 11 or on opensuse 11 for 8.3
I'm planning on rolling my own from source as well.
Dave Kerr
Chris spotts wrote:
Thanks, I got it installed from source and got uuid-ossp working. One
of the easier installs from source for a major app that I've done.
Appreciate
On Sat, 2009-04-04 at 11:36 -0500, Chris spotts wrote:
> Well, the only file that shows up is the uninstall file? Thats a
> little odd.
I see these files on my 8.4 :
/usr/share/pgsql/contrib/uninstall_uuid-ossp.sql
/usr/share/pgsql/contrib/uuid-ossp.sql
See second one. It is there. uuid support
Thanks, I got it installed from source and got uuid-ossp working. One
of the easier installs from source for a major app that I've done.
Appreciate the help.
Chris
On Sat, 2009-04-04 at 11:40 -0400, Tom Lane wrote:
> Chris spotts writes:
> > I’m brand new to Postgresql and working on moving an
Well, the only file that shows up is the uninstall file? Thats a little
odd.
Looks like I'll be rebuilding from source on monday...joyous.
On Sat, 2009-04-04 at 11:40 -0400, Tom Lane wrote:
> Chris spotts writes:
> > I’m brand new to Postgresql and working on moving an
> > existing large DB into i
Bruce McAlister <[EMAIL PROTECTED]> writes:
>> Bizarre ... I've never heard of a Unix system that didn't consider that
>> a default place to look. Unless this is a 64-bit machine and uuid
>> should have installed itself in /usr/lib64?
> It is a rather peculiar issue, I also assumed that it would
>
> Bizarre ... I've never heard of a Unix system that didn't consider that
> a default place to look. Unless this is a 64-bit machine and uuid
> should have installed itself in /usr/lib64?
>
It is a rather peculiar issue, I also assumed that it would check the
standard locations, but I thought
Bruce McAlister <[EMAIL PROTECTED]> writes:
> In addition to the missing configure option, it turned out to be missing
> LDFLAGS parameters, I just added -L/usr/lib to LDFLAGS and it all built
> successfully now.
Bizarre ... I've never heard of a Unix system that didn't consider that
a default pla
1 - 100 of 122 matches
Mail list logo
