Mark,A model that intended to try and guarantee uniqueness would provide aUUID generation service for the entire host, that was not specific to
any application, or database, possibly accessible via the loopbackaddress. It would ensure that at any given time, either the time isnew, or the sequence i
Gevik,>uniqueness is never a guaranteed. that is according to the RFC docs.>uniqueness is never a guaranteed in the sense that there is a tiny>chance someone of the other side of the planet might generate the same
>guid. As much as I learned, it is recommended to give information about "grade of un
Joshua,> So now it's MySQL users' turn to say, "Sure, but speed isn't
> everything" :-)"Sure, but speed isn't everything... We can accept 02/31/2006 as a validdate. Let's see PostgreSQL do that!"I got the joke :)But: it is still a problem when converting. As accepting 2006-02-31 as a valid date
Tom,This sort of thing normally requires more thought than just removingthe safety check. What happens when the python code does/doesn't return
a value, in both cases (declared return type void or not)?python functions are specified to return "None", if no return is given. I recommend to also see
Neil,I have written a patch causes> the PLy_traceback function to fully log the traceback. The
> output looks just like the traceback output provided by the> python interpreter.Can any PL/Python folks comment on whether they want this patch?I am just a humble user of PL/Py, but tracebacks are very
Matthew T. O'Connor schrieb:
In the windows service world, is there any reason pg_autovacuum should
ever give up? The reason I had it give up was so that it didn't
accidently run against a different postgresql instance. I don't think
that will happen in the windows service world. I think it s
I suggest to alter the
pg_restore --help output from
-
Usage:
pg_restore [OPTION]... [FILE]
General options:
-d, --dbname=NAMEoutput database name
-f, --file=FILENAME output file name
---
to:
--
