[HACKERS] uuid type for postgres

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

Re: [HACKERS] uuid type for postgres

with the source code. That is, an identical requirement to the one that postgres itself uses. -- Nathan Wagner ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

Re: [HACKERS] uuid type for postgres

i'm not doing proper error checking, and i'm not sure how to log or throw an error even if i detect one. Also, I have only compiled it on Mac OS 10.3, I'll want to test it on my linux box. -- Nathan Wagner ---(end of broadcast)--- TIP 6: explain

Re: [HACKERS] uuid type for postgres

it for suggestions, comments, and so we have something that isn't vaporware to argue about. :) -- Nathan Wagner ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

Re: [HACKERS] uuid type for postgres

school is going to take up the bulk of my free time. And of course I'll still need time to play around with my ticketing and gis databases i'm developing. -- Nathan Wagner ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please

Re: [HACKERS] uuid type for postgres

. Different applications have different goals. Unguessability might be important in some contexts. -- Nathan Wagner ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org

Re: [HACKERS] uuid type for postgres

library you were using, but the one i used is not LGPL. I posted earlier the copyright and license portion of the readme. No relicensing would be necessary. -- Nathan Wagner ---(end of broadcast)--- TIP 5: don't forget to increase your free space

Re: [HACKERS] uuid type for postgres

a new version later today. There really won't be any new functionality, it's just code clean up. -- Nathan Wagner ---(end of broadcast)--- TIP 6: explain analyze is your friend

Re: [HACKERS] uuid type for postgres

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 that unguessable numbers were sometimes useful. -- Nathan Wagner

Re: [HACKERS] uuid type for postgres

that folks could look at the code i was proposing if they wished. -- Nathan Wagner ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org

Re: [HACKERS] PG 9.0 and standard_conforming_strings

On Wed, 03 Feb 2010 14:41:13 -0500, Tom Lane t...@sss.pgh.pa.us wrote: Indeed it is, which is one of the reasons to be cautious with changing it. We've been telling people to move away from \' for a long time, but actually flipping the switch that will make their apps insecure is not

Re: [HACKERS] ossp-uuid Contrib Patch

On Mon, Sep 10, 2012 at 04:23:00PM -0700, David E. Wheeler wrote: Well given that OSSP seems to be abandon ware (no activity since July 2008), it might be time to dump it in favor of something else. Perhaps this would be a good time to bring up my uuid code again. I've got a module for uuid

Re: [HACKERS] psql line number reporting from stdin

On Sat, 26 Nov 2011 22:36:15 +0200, Peter Eisentraut wrote: There is a long-standing oddity in psql that running psql -f foo.sql returns error messages with file name and line number, like psql:foo.sql:1: ERROR: syntax error at or near foo but running psql foo.sql does not. I suggest we

Re: [HACKERS] Add EXTRA_CFLAGS to configure

On Wed, Oct 28, 2015 at 02:42:19PM +0100, Robert Haas wrote: > On Wed, Oct 28, 2015 at 2:17 PM, Andres Freund wrote: > >> I use COPT for this purpose. > > > > Unless I miss something you can't just pass that to configure though, > > right? I.e. it has to be passed to each make

Re: [HACKERS] fortnight interval support

On Tue, Oct 27, 2015 at 01:52:11PM +, Nathan Wagner wrote: > On Mon, Oct 26, 2015 at 01:58:52PM -0400, Robert Haas wrote: > > Aw, you're no fun. select '1 fortnight'::interval => '14 days' would be > > cool. > > Patch attached... This isn't necessarily bad, but

Re: [HACKERS] fortnight interval support

On Tue, Oct 27, 2015 at 12:04:55PM -0500, Merlin Moncure wrote: > On Tue, Oct 27, 2015 at 8:52 AM, Nathan Wagner <nw...@hydaspes.if.org> wrote: > > On Mon, Oct 26, 2015 at 01:58:52PM -0400, Robert Haas wrote: > >> Aw, you're no fun. select '1 fortnight'::interval => '1

Re: [HACKERS] fortnight interval support

On Wed, Oct 28, 2015 at 08:17:25AM +1300, Gavin Flower wrote: > You trying to get PostgreSQL banned in France??? :-) > > When I was learning French many years ago, I was told that the French > consider their fortnight to be 15 days!!! What, it's a "fortnight", not a "quinzaine". You have no

Re: [HACKERS] bugs and bug tracking

On Tue, Oct 20, 2015 at 10:39:55AM -0700, Joshua D. Drake wrote: > So where are we at on this? Well, I can't speak to where we are, but my system is up, running, and seems to work well, It even attracts a few visitors. I have been meaning to write a triage interface, but I have been stuck doing

[HACKERS] fortnight interval support

On Mon, Oct 26, 2015 at 01:58:52PM -0400, Robert Haas wrote: > Aw, you're no fun. select '1 fortnight'::interval => '14 days' would be cool. Patch attached... :) % psql -p 5433 -d template1 -h localhost psql (9.4.5, server 9.6devel) WARNING: psql major version 9.4, server major version 9.6.

Re: [HACKERS] patch for geqo tweaks

On Wed, Nov 04, 2015 at 12:51:52PM -0500, Tom Lane wrote: > Nathan Wagner <nw...@hydaspes.if.org> writes: > > I have two patches to make the geqo initialization and mutation > > slightly better. > > > The first adjusts the mutation swaps to avoid having to re-pick

Re: [HACKERS] September 2015 Commitfest

On Sat, Oct 31, 2015 at 12:08:58PM -0400, Tom Lane wrote: > Nathan Wagner <nw...@hydaspes.if.org> writes: > > Second, it would be convenient if there were a make target that would > > set up a test environment. Effectively do what the 'make check' does, > > but do

Re: [HACKERS] patch for geqo tweaks

On Wed, Nov 04, 2015 at 12:51:52PM -0500, Tom Lane wrote: > As for the second part, I had to look up Fisher-Yates ;-) but after > having read Wikipedia's entry about it I think this is a good change. > The code's shorter and more efficient, and it should mathematically > provide an

Re: [HACKERS] patch for geqo tweaks

On Fri, Nov 06, 2015 at 11:19:00AM -0500, Tom Lane wrote: > Nathan Wagner <nw...@hydaspes.if.org> writes: > > I see you committed a modified version of my patch in commit > > 59464bd6f928ad0da30502cbe9b54baec9ca2c69. > > > You changed the tour[0] to be hardco

Re: [HACKERS] patch for geqo tweaks

On Fri, Nov 06, 2015 at 11:45:38AM -0500, Tom Lane wrote: > However, really the whole argument is moot, because I notice that > geqo_mutation() is only called in the "#ifdef CX" code path, which > we don't use. I suppose someone could turn it on via a compiler define. > So there's little point

Re: [HACKERS] patch for geqo tweaks

On Fri, Nov 06, 2015 at 02:16:41PM -0500, Tom Lane wrote: > Uh, what? It's not by any means turned off by default. > > postgres=# select name,setting from pg_settings where name like '%geqo%'; > name | setting > -+- > geqo| on [snip]

Re: [HACKERS] September 2015 Commitfest

On Sat, Oct 31, 2015 at 08:03:59AM +0100, Robert Haas wrote: > +1. FWIW, I'm willing to review some patches for this CommitFest, but > if the committers have to do first-round review as well as > committer-review of every patch in the CommitFest, this is going to be > long, ugly, and painful. We

Re: [HACKERS] bugs and bug tracking

On Wed, Oct 07, 2015 at 03:06:50PM -0400, Stephen Frost wrote: > * Nathan Wagner (nw...@hydaspes.if.org) wrote: > > I have added full text searching to my tracker. I only index the first > > 50 KB of each message. There's apparently a one MB limit on that > > anyway, which

Re: [HACKERS] bugs and bug tracking

I have added full text searching to my tracker. I only index the first 50 KB of each message. There's apparently a one MB limit on that anyway, which a few messages exceed. I figure anything important is probably in the first 50KB. I could be wrong. I could re-index fairly easily. It seems

Re: [HACKERS] bugs and bug tracking

On Tue, Oct 06, 2015 at 01:17:48PM -0400, Bruce Momjian wrote: > I do think we rushed to choose a tracker a little too quickly. Have we chosen one? > Let me explain, from a high level, what a new tracker will change in > our workflow. [snip] I won't quote your whole message, which I

Re: [HACKERS] bugs and bug tracking

On Tue, Oct 06, 2015 at 10:57:42AM -0700, Josh Berkus wrote: > On 10/06/2015 10:17 AM, Bruce Momjian wrote: > > Therefore, our current default behavior is to ignore user reports, > > unless someone takes an action to reply, record, or retain the email for > > later review. What a tracker does

[HACKERS] patch for geqo tweaks

against commit 49124613f134b04594b1a5c46368eb0a5db16d4b (i.e. tip of master as of when I re-made the diff). On my system the patches pass a ./configure; make; make check -- nw >From c7f3c7cc37f943481b2358149210789be3d39ee9 Mon Sep 17 00:00:00 2001 From: Nathan Wagner <n...@hydaspes.if.org>

Re: [HACKERS] No Issue Tracker - Say it Ain't So!]

On Sun, Oct 04, 2015 at 04:30:49PM -0700, Josh Berkus wrote: > That would be the key part, wouldn't it? Nice that you have [code to > store and parse email messages]. Yeah. It actually made most of the work pretty easy. It's available with a bunch of other code at https://pd.if.org/git/ if

Re: [HACKERS] No Issue Tracker - Say it Ain't So!]

I don't have the original message for this thread, so I arbitrarily picked a message to reply to. Since what has been asked for is a bug *tracker*, and we already have a bugs mailing list, I put together something. I downloaded the archives for pgsql-bugs, and fed them into a database. This

[HACKERS] bugs and bug tracking

So, in order to do some clean up and see how my pgbugs page (https://granicus.if.org/pgbugs/) might actually work I've been going through bugs and marking their status. A lot of questions arise. A lot of the reports aren't bugs at all, but requests for help. My guess is that the users either

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

I don't have the original message for this thread, so I arbitrarily picked a message to reply to. Since what has been asked for is a bug *tracker*, and we already have a bugs mailing list, I put together something. I downloaded the archives for pgsql-bugs, and fed them into a database. This

Re: [HACKERS] bugs and bug tracking

On Tue, Oct 06, 2015 at 12:04:11PM -0500, Jaime Casanova wrote: > I like how this page is looking now, good work. Thank you. > Now, AFAIU from previous mails part of the reason to have a bug > tracker is to make easy to know when a bug was fixed. Which should be > interpreted as: which versions

Re: [HACKERS] Fix number skipping in to_number

On Thu, Aug 17, 2017 at 12:33:02PM +0100, Oliver Ford wrote: > Ok I've made that change in the attached v3. I'm not sure as I'm on > en_US.UTF-8 locale too. Maybe something Windows specific? This patch applies against master (8485a25a), compiles, and passes a make check. I tested both on my

Re: [HACKERS] Fix number skipping in to_number

On Mon, Sep 25, 2017 at 07:52:19PM +0100, Oliver Ford wrote: > Thanks for your review. The issue is that Oracle throws errors on many > more input cases than Postgres does, so making it exactly like Oracle > could break a lot of existing users. E.g. to_number ('123,000', '999') > returns '123' on