Re: [PATCHES] [HACKERS] Text - C string

2008-05-04 Thread Tom Lane
Brendan Jurd [EMAIL PROTECTED] writes: Well ... if somebody does want to change the representation of xml down the road, he's going to have to touch all the sites where the code converts to and from cstring anyway, right? True. With that in mind, please find attached my followup patch. It

Re: [PATCHES] pg_postmaster_reload_time() patch

2008-05-04 Thread Tom Lane
George Gensure [EMAIL PROTECTED] writes: The new function name is pg_conf_load_time() Applied with revisions. I'm now using LWLocks only on the backend in order to protect the PgReloadTime from mid copy reads. This may prove to be unnecessary, since the code to handle HUPs seems to be

Re: [PATCHES] [HACKERS] Multiline privileges in \z

2008-05-04 Thread Brendan Jurd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, May 4, 2008 at 10:55 AM, Tom Lane wrote: Andrew Dunstan writes: Wouldn't this expression: pg_catalog.array_to_string(c.relacl, chr(10)) be better expressed as pg_catalog.array_to_string(c.relacl, E'\n') +1 ...

Re: [PATCHES] Fix \dT enum in psql

2008-05-04 Thread Andrew Dunstan
David Fetter wrote: Folks, In psql, \dT doesn't show the elements for enums. Please find patch vs. CVS TIP attached which fixes this per the following TODO item: http://archives.postgresql.org/pgsql-hackers/2008-01/msg00826.php I notice that this patch adds an Elements column to

Re: [PATCHES] Fix \dT enum in psql

2008-05-04 Thread David Fetter
On Sun, May 04, 2008 at 06:40:51PM -0400, Andrew Dunstan wrote: David Fetter wrote: Folks, In psql, \dT doesn't show the elements for enums. Please find patch vs. CVS TIP attached which fixes this per the following TODO item:

Re: [PATCHES] Fix \dT enum in psql

2008-05-04 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes: I notice that this patch adds an Elements column to the output of \dT, which will only be used by enum types. That seems rather ... cluttered. But it'll only be in \dT+ anyway, no? regards, tom lane -- Sent via pgsql-patches

Re: [PATCHES] Sorting writes during checkpoint

2008-05-04 Thread Greg Smith
On Sun, 4 May 2008, Tom Lane wrote: However, I am completely unable to measure any performance improvement from it. Given the possible risk of out-of-memory failures, I think the patch should not be applied without some direct proof of performance benefits, and I don't see any. Fair enough.

Re: [PATCHES] temporal version of generate_series()

2008-05-04 Thread Tom Lane
H.Harada [EMAIL PROTECTED] writes: Here's the sync and updated patch. It contains strict in catalog as well. Applied with some revisions --- I added a timestamptz version; it didn't seem very appropriate to have only a timestamp version. You can't just pick a convenient-looking OID, you must

Re: [PATCHES] Sorting writes during checkpoint

2008-05-04 Thread Tom Lane
Greg Smith [EMAIL PROTECTED] writes: On Sun, 4 May 2008, Tom Lane wrote: However, I am completely unable to measure any performance improvement from it. Given the possible risk of out-of-memory failures, I think the patch should not be applied without some direct proof of performance

Re: [PATCHES] Fix \dT enum in psql

2008-05-04 Thread Andrew Dunstan
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: I notice that this patch adds an Elements column to the output of \dT, which will only be used by enum types. That seems rather ... cluttered. But it'll only be in \dT+ anyway, no? Not in this

Re: [PATCHES] Fix \dT enum in psql

2008-05-04 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: But it'll only be in \dT+ anyway, no? Not in this patch. Hmmm ... given that a long list of enum members would bloat the output quite a lot, I think I'd vote for putting it in \dT+. regards, tom lane -- Sent

Re: [PATCHES] Fix \dT enum in psql

2008-05-04 Thread Andrew Dunstan
David Fetter wrote: On Sun, May 04, 2008 at 07:49:25PM -0400, Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: But it'll only be in \dT+ anyway, no? Not in this patch. Hmmm ... given that a long list of enum members would bloat the

Re: [PATCHES] options for RAISE statement

2008-05-04 Thread Tom Lane
Pavel Stehule [EMAIL PROTECTED] writes: this patch adds possibility to set additional options (SQLSTATE, DETAIL, DETAIL_LOG and HINT) for RAISE statement, I looked this over briefly. A couple of comments: * Raising errors via hard-coded SQLSTATEs seems pretty unfriendly, at least for cases

Re: [PATCHES] [HACKERS] Multiline privileges in \z

2008-05-04 Thread Andrew Dunstan
Brendan Jurd wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Apr 18, 2008 at 2:37 AM, Tom Lane wrote: The function names in the patch need schema-qualification in case pg_catalog is not first in the search path. Ah, yes. I should have seen that. Thanks Tom. New

Re: [PATCHES] temporal version of generate_series()

2008-05-04 Thread H . Harada
2008/5/5 Tom Lane [EMAIL PROTECTED]: Applied with some revisions --- I added a timestamptz version; it didn't seem very appropriate to have only a timestamp version. You can't just pick a convenient-looking OID, you must use one that the unused_oids script reports as free. I didn't

Re: [PATCHES] Sorting writes during checkpoint

2008-05-04 Thread Greg Smith
On Sun, 4 May 2008, Tom Lane wrote: Well, I tried a pgbench test similar to that one --- on smaller hardware than was reported, so it was a bit smaller test case, but it should have given similar results. My pet theory on cases where sorting will help suggests you may need a write-caching

Re: [PATCHES] options for RAISE statement

2008-05-04 Thread Pavel Stehule
Hello I thing, all your comments are not problem. I'll send new version this week. Thank You Pavel Stehule 2008/5/5 Tom Lane [EMAIL PROTECTED]: Pavel Stehule [EMAIL PROTECTED] writes: this patch adds possibility to set additional options (SQLSTATE, DETAIL, DETAIL_LOG and HINT) for RAISE

Re: [PATCHES] Sorting writes during checkpoint

2008-05-04 Thread Tom Lane
Greg Smith [EMAIL PROTECTED] writes: On Sun, 4 May 2008, Tom Lane wrote: Well, I tried a pgbench test similar to that one --- on smaller hardware than was reported, so it was a bit smaller test case, but it should have given similar results. ... If you're not offloading to another device