On 2019-Jul-13, Jose Luis Tallon wrote:
> Considering the later arguments on-list, I plan on submitting a more
> elaborate patchset integrating the feedback received so far, and along the
> following lines:
>
> - uuid type, v4 generation and uuid_version() in core
>
> - Provide a means to
On 7/14/19 9:40 PM, Peter Eisentraut wrote:
On 2019-07-13 17:13, Fabien COELHO wrote:
What about avoiding a redirection with something like:
Datum (* const pg_random_uuid)(PG_FUNCTION_ARGS) = gen_random_uuid;
That seems very confusing.
Dunno. Possibly. The user does not have to look at the
On 2019-07-13 17:13, Fabien COELHO wrote:
>>> What about avoiding a redirection with something like:
>>>
>>> Datum (* const pg_random_uuid)(PG_FUNCTION_ARGS) = gen_random_uuid;
>>
>> That seems very confusing.
>
> Dunno. Possibly. The user does not have to look at the implementation, and
>
Hello Jose,
Considering the later arguments on-list, I plan on submitting a more
elaborate patchset integrating the feedback received so far, and along the
following lines:
- uuid type, v4 generation and uuid_version() in core
- Provide a means to rename/supercede extensions keeping
Hello Peter,
About doc: I'd consider "generation" instead of "generating" as a
secondary index term.
We do use the "-ing" form for other secondary index terms. It's useful
because the concatenation of primary and secondary term should usually
make a phrase of some sort. The alternative
On 2019-07-13 08:08, Fabien COELHO wrote:
> About doc: I'd consider "generation" instead of "generating" as a
> secondary index term.
We do use the "-ing" form for other secondary index terms. It's useful
because the concatenation of primary and secondary term should usually
make a phrase of
Hello Jose,
Got it, and done. Please find attached a v2 patch with the upgrade script
included.
Patch v2 applies cleanly. Compiles cleanly (once running configure
--with-uuid=...). Local make check ok. Doc build ok.
There are no tests, I'd suggest to add some under sql & change expected
Hello Peter,
A possible option 3 is to keep the function in pgcrypto but change
its C code to call the core code.
Updated patch with this change included.
Patch applies cleanly, compiles (both pg and pgcrypto). make check (global
and pgcrypto) ok. Doc generation ok. Minor comments:
Alvaro Herrera writes:
> On 2019-Jul-05, Peter Eisentraut wrote:
>> (There is also precedent for redirecting the extension function to the
>> internal one by changing the SQL-level function definition using CREATE
>> OR REPLACE FUNCTION ... LANGUAGE INTERNAL. But that seems more
>> complicated
On 2019-Jul-05, Peter Eisentraut wrote:
> (There is also precedent for redirecting the extension function to the
> internal one by changing the SQL-level function definition using CREATE
> OR REPLACE FUNCTION ... LANGUAGE INTERNAL. But that seems more
> complicated and would require a new
On 5/7/19 11:00, Peter Eisentraut wrote:
On 2019-07-05 00:08, Jose Luis Tallon wrote:
On 4/7/19 17:30, Alvaro Herrera wrote:
On 2019-Jul-04, Tom Lane wrote:
A possible option 3 is to keep the function in pgcrypto but change
its C code to call the core code.
Updated patch with this change
On 2019-07-05 00:08, Jose Luis Tallon wrote:
> On 4/7/19 17:30, Alvaro Herrera wrote:
>> On 2019-Jul-04, Tom Lane wrote:
>>
>>> A possible option 3 is to keep the function in pgcrypto but change
>>> its C code to call the core code.
Updated patch with this change included.
(There is also
On 4/7/19 17:30, Alvaro Herrera wrote:
On 2019-Jul-04, Tom Lane wrote:
A possible option 3 is to keep the function in pgcrypto but change
its C code to call the core code.
This seems most reasonable, and is what José Luis proposed upthread. We
don't have to bump the pgcrypto extension
On 2019-Jul-04, Tom Lane wrote:
> A possible option 3 is to keep the function in pgcrypto but change
> its C code to call the core code.
This seems most reasonable, and is what José Luis proposed upthread. We
don't have to bump the pgcrypto extension version, as nothing changes
for pgcrypto
Peter Eisentraut writes:
> I think the alternatives are:
> 1. We keep the code in both places. This is fine. There is no problem
> with having the same C function or the same SQL function name in both
> places.
> 2. We remove the C function from pgcrypto and make an extension version
> bump.
On 2019-07-02 17:09, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 2019-06-30 14:50, Fabien COELHO wrote:
>>> I'm wondering whether pg_random_uuid() should be taken out of pgcrypto if
>>> it is available in core?
>
>> That would probably require an extension version update dance in
>>
Peter Eisentraut writes:
> On 2019-06-30 14:50, Fabien COELHO wrote:
>> I'm wondering whether pg_random_uuid() should be taken out of pgcrypto if
>> it is available in core?
> That would probably require an extension version update dance in
> pgcrypto. I'm not sure if it's worth that.
On 2/7/19 9:26, Peter Eisentraut wrote:
On 2019-06-30 14:50, Fabien COELHO wrote:
I'm wondering whether pg_random_uuid() should be taken out of pgcrypto if
it is available in core?
That would probably require an extension version update dance in
pgcrypto. I'm not sure if it's worth that.
On 2019-06-30 14:50, Fabien COELHO wrote:
> I'm wondering whether pg_random_uuid() should be taken out of pgcrypto if
> it is available in core?
That would probably require an extension version update dance in
pgcrypto. I'm not sure if it's worth that. Thoughts?
--
Peter Eisentraut
On Fri, Jun 28, 2019 at 03:24:03PM -0700, Peter Geoghegan wrote:
On Mon, Apr 8, 2019 at 11:04 PM Peter Eisentraut
wrote:
Yeah, I think implementing a v4 generator in core would be trivial and
address almost everyone's requirements.
FWIW, I think that we could do better with nbtree page
Hello Peter,
Yeah, I think implementing a v4 generator in core would be trivial and
address almost everyone's requirements.
Here is a proposed patch for this. I did a fair bit of looking around
in other systems for a naming pattern but didn't find anything
consistent. So I ended up just
On Mon, Apr 8, 2019 at 11:04 PM Peter Eisentraut
wrote:
> Yeah, I think implementing a v4 generator in core would be trivial and
> address almost everyone's requirements.
FWIW, I think that we could do better with nbtree page splits given
sequential UUIDs of one form or another [1]. We could
On 11/6/19 13:11, Peter Eisentraut wrote:
On 2019-06-11 12:31, Jose Luis Tallon wrote:
I wonder whether re-implementing some more of the extension's (ie. UUID
v5) in terms of PgCrypto and in-core makes sense / would actually be
accepted into core?
Those other versions are significantly more
On 2019-06-11 12:31, Jose Luis Tallon wrote:
> I wonder whether re-implementing some more of the extension's (ie. UUID
> v5) in terms of PgCrypto and in-core makes sense / would actually be
> accepted into core?
Those other versions are significantly more complicated to implement,
and I don't
On 11/6/19 10:49, Peter Eisentraut wrote:
On 2019-04-09 08:04, Peter Eisentraut wrote:
On 2019-04-08 23:06, Andres Freund wrote:
The randomness based UUID generators don't really have dependencies, now
that we have a dependency on strong randomness. I kinda thing the
dependency argument
On 2019-04-09 08:04, Peter Eisentraut wrote:
> On 2019-04-08 23:06, Andres Freund wrote:
>> The randomness based UUID generators don't really have dependencies, now
>> that we have a dependency on strong randomness. I kinda thing the
>> dependency argument actually works *against* uuid-ossp -
On 2019-04-08 23:06, Andres Freund wrote:
> The randomness based UUID generators don't really have dependencies, now
> that we have a dependency on strong randomness. I kinda thing the
> dependency argument actually works *against* uuid-ossp - precisely
> because of its dependencies (which also
Hi,
On 2019-04-08 11:06:57 -0400, Robert Haas wrote:
> That's not really a compelling reason, though, because anybody who
> needs UUIDs can always install the extension. And on the other hand,
> if we moved UUID support into core, then we'd be adding a hard compile
> dependency on one of the
On 8/4/19 17:06, Robert Haas wrote:
On Sun, Apr 7, 2019 at 10:15 AM David Fetter wrote:
I see some.
UUIDs turn out to be super useful in distributed systems to give good
guarantees of uniqueness without coordinating with a particular node.
Such systems have become a good bit more common since
Robert Haas writes:
> My biggest gripe about uuid-ossp is that the name is stupid. I wish
> we could see our way clear to renaming that extension to just 'uuid',
> because as J.L. says, virtually nobody's actually compiling against
> the OSSP library any more.
+1
There's no ALTER EXTENSION
On Sun, Apr 7, 2019 at 10:15 AM David Fetter wrote:
> I see some.
>
> UUIDs turn out to be super useful in distributed systems to give good
> guarantees of uniqueness without coordinating with a particular node.
> Such systems have become a good bit more common since the most recent
> time this
On Sat, Apr 06, 2019 at 12:35:47PM -0400, Tom Lane wrote:
> Jose Luis Tallon writes:
> > While working on an application, the need arose to be able
> > efficiently differentiate v4/v5 UUIDs (for use in partial indexes, among
> > others)
> > ... so please find attached a trivial patch which
On 6/4/19 18:35, Tom Lane wrote:
Jose Luis Tallon writes:
While working on an application, the need arose to be able
efficiently differentiate v4/v5 UUIDs (for use in partial indexes, among
others)
... so please find attached a trivial patch which adds the
functionality.
No particular
Jose Luis Tallon writes:
> While working on an application, the need arose to be able
> efficiently differentiate v4/v5 UUIDs (for use in partial indexes, among
> others)
> ... so please find attached a trivial patch which adds the
> functionality.
No particular objection...
> I'm
Hackers,
While working on an application, the need arose to be able
efficiently differentiate v4/v5 UUIDs (for use in partial indexes, among
others)
... so please find attached a trivial patch which adds the
functionality. The "uuid_version_bits()" function (from the test suite?)
seems
35 matches
Mail list logo
