Re: [HACKERS] Should enum GUCs be listed as such in config.sgml?

2008-07-01 Thread Magnus Hagander
Tom Lane wrote: > Currently, config.sgml still describes the new "enum" GUC variables > as being of type "string" --- but pg_settings says they are "enum". > This is not very consistent, but I wonder whether changing the docs > would be more confusing or less so. I note that section 18.1 doesn't >

Re: [HACKERS] Limits of backwards compatibility for psql's \d commands

2008-07-01 Thread Tom Lane
"Joshua D. Drake" <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> ... So it's just 7.3 that's worth debating, I think. > EOL is EOL, why is the question even being asked? Well, pg_dump still supports servers back to 7.0 (and yes I do test that now and again). psql probably doesn't need to suppo

Re: [HACKERS] Limits of backwards compatibility for psql's \d commands

2008-07-01 Thread Joshua D. Drake
Tom Lane wrote: I'm fooling around with Guillaume Lelarge's patch to make psql's \d commands work with older server versions. The patch as submitted works with servers back to 7.4 (modulo a small bug or two). I tried to see what it'd take to make it work with 7.3. I count about a dozen trivial

Re: [HACKERS] Limits of backwards compatibility for psql's \d commands

2008-07-01 Thread Devrim GÜNDÜZ
On Tue, 2008-07-01 at 22:33 -0400, Tom Lane wrote: > Pre-7.3 server versions seem entirely out of the realm of reason > because they lack schema support, meaning all of those "pg_catalog." > prefixes break, not to mention the joins to pg_namespace and the > "schema" output columns. So it's just 7

Re: [HACKERS] Limits of backwards compatibility for psql's \d commands

2008-07-01 Thread Greg Sabino Mullane
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > I didn't see a simple fix right away. This seems a bit more work than > is justified for a server version that the community has officially > dropped support for, but I wonder if anyone feels hot about it? > > Pre-7.3 server versions seem ent

[HACKERS] Limits of backwards compatibility for psql's \d commands

2008-07-01 Thread Tom Lane
I'm fooling around with Guillaume Lelarge's patch to make psql's \d commands work with older server versions. The patch as submitted works with servers back to 7.4 (modulo a small bug or two). I tried to see what it'd take to make it work with 7.3. I count about a dozen trivial diffs and about t

Re: [HACKERS] A new take on the foot-gun meme

2008-07-01 Thread Gregory Williamson
In further OT Gregory Stark wrote: > > "Shane Ambler" <[EMAIL PROTECTED]> writes: > > > > > >> Robert Treat wrote: > >> > >> > So is that a "golf club gun"? > > >>> Careful what you wish for > >>> http://www.totallyabsurd.com/12gaugegolfclub.htm > >>> > >> I r

OT: Re: [HACKERS] A new take on the foot-gun meme

2008-07-01 Thread Steve Crawford
Gregory Stark wrote: "Shane Ambler" <[EMAIL PROTECTED]> writes: Robert Treat wrote: So is that a "golf club gun"? Careful what you wish for http://www.totallyabsurd.com/12gaugegolfclub.htm I reckon they watched Caddyshack (I think that was the one) and thought th

[HACKERS] Please claim review items for commit fest!

2008-07-01 Thread Josh Berkus
Hackers, Just in case anyone was unclear, this is how we're trying things for this commitfest: 1) Starting RIGHT NOW, reviewers should claim review items they are interested in or specially qualified to review. 2) This weekend, I will check for all items which don't have one or more reviewers an

[HACKERS] Please claim review items for commit fest!

2008-07-01 Thread Josh Berkus
Hackers, Just in case anyone was unclear, this is how we're trying things for this commitfest: 1) Starting RIGHT NOW, reviewers should claim review items they are interested in or specially qualified to review. 2) This weekend, I will check for all items which don't have one or more reviewers an

Re: [HACKERS] TODO assignment

2008-07-01 Thread Josh Berkus
Jiri, I don't know of anyone currently working on the "apply permissions to all objects" TODO. You're welcome to take a stab at it. --Josh Josh Berkus PostgreSQL @ Sun San Francisco 415-752-2500 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subs

Re: [HACKERS] Commitfest status?

2008-07-01 Thread Josh Berkus
On Tue, 01 Jul 2008 16:19:39 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: > Well, it's July 1, and time for another commit fest to begin. > Do we have all the submitted patches queued up at > http://wiki.postgresql.org/wiki/CommitFest:2008-07 ? I think Bruce and I have added everything submitted to

[HACKERS] Should enum GUCs be listed as such in config.sgml?

2008-07-01 Thread Tom Lane
Currently, config.sgml still describes the new "enum" GUC variables as being of type "string" --- but pg_settings says they are "enum". This is not very consistent, but I wonder whether changing the docs would be more confusing or less so. I note that section 18.1 doesn't mention the enum alternat

Re: [HACKERS] Commitfest status?

2008-07-01 Thread Alvaro Herrera
Joe Conway wrote: > I haven't yet committed the dblink patch posted here: > > http://archives.postgresql.org/pgsql-patches/2008-06/msg00016.php > > Should I post it on the wiki before committing? Either way I'll commit > in the next day or so. It doesn't matter. Patches are only listed in the

Re: [HACKERS] Commitfest status?

2008-07-01 Thread Joe Conway
Tom Lane wrote: Well, it's July 1, and time for another commit fest to begin. Do we have all the submitted patches queued up at http://wiki.postgresql.org/wiki/CommitFest:2008-07 ? I haven't yet committed the dblink patch posted here: http://archives.postgresql.org/pgsql-patches/2008-06/msg00

[HACKERS] Commitfest status?

2008-07-01 Thread Tom Lane
Well, it's July 1, and time for another commit fest to begin. Do we have all the submitted patches queued up at http://wiki.postgresql.org/wiki/CommitFest:2008-07 ? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] Location for pgstat.stat

2008-07-01 Thread Tom Lane
Magnus Hagander <[EMAIL PROTECTED]> writes: > Alvaro Herrera wrote: >> Well, it doesn't :-) No database or table will be processed until stat >> entries are created, and then I think it will first wait until enough >> activity gathers to take any actions at all. > That's not actualliy not affecte

Re: [HACKERS] Location for pgstat.stat

2008-07-01 Thread Greg Smith
On Tue, 1 Jul 2008, Tom Lane wrote: Magnus Hagander <[EMAIL PROTECTED]> writes: Tom Lane wrote: Hmm ... that would almost certainly result in the stats being lost over a system shutdown. How much do we care? Only for those who put it on a ramdrive. The default, unless you move/sync it off,

Re: [HACKERS] Location for pgstat.stat

2008-07-01 Thread Magnus Hagander
Alvaro Herrera wrote: > Magnus Hagander wrote: > >> Not sure. I guess my own personal concern would be how badly is >> autovacuum affected by having to start off a blank set of stats? Any >> other uses I have I think are capable of dealing with reset-to-zero states. > > Well, it doesn't :-) No d

Re: [HACKERS] A new take on the foot-gun meme

2008-07-01 Thread Gregory Stark
"Shane Ambler" <[EMAIL PROTECTED]> writes: > Robert Treat wrote: > >>> So is that a "golf club gun"? >> >> Careful what you wish for >> http://www.totallyabsurd.com/12gaugegolfclub.htm > > I reckon they watched Caddyshack (I think that was the one) and thought they > could get the patent befo

Re: [HACKERS] Location for pgstat.stat

2008-07-01 Thread Alvaro Herrera
Magnus Hagander wrote: > Not sure. I guess my own personal concern would be how badly is > autovacuum affected by having to start off a blank set of stats? Any > other uses I have I think are capable of dealing with reset-to-zero states. Well, it doesn't :-) No database or table will be processe

Re: [HACKERS] Location for pgstat.stat

2008-07-01 Thread Magnus Hagander
Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> writes: >> Tom Lane wrote: >>> Hmm ... that would almost certainly result in the stats being lost over >>> a system shutdown. How much do we care? > >> Only for those who put it on a ramdrive. The default, unless you >> move/sync it off, would

Re: [HACKERS] Fairly serious bug induced by latest guc enum changes

2008-07-01 Thread Tom Lane
Magnus Hagander <[EMAIL PROTECTED]> writes: > Not having looked at md.c (I confess...) but don't we have a problem in > case we have closed the file without fsyncing it, and then change the > fsync parameter? Well, we don't promise to retroactively fsync stuff we didn't before; and I wouldn't expe

Re: [HACKERS] Location for pgstat.stat

2008-07-01 Thread Tom Lane
Magnus Hagander <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Hmm ... that would almost certainly result in the stats being lost over >> a system shutdown. How much do we care? > Only for those who put it on a ramdrive. The default, unless you > move/sync it off, would still be the same as it

Re: [HACKERS] Fairly serious bug induced by latest guc enum changes

2008-07-01 Thread Magnus Hagander
Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> writes: >> Or are you talking about changing the variable "fsync"? If so, doesn't >> "fsync=off" also change the behavior of other parts of the code, so it's >> not just WAL, which means it'd be pretty unsafe *anyway* unless you >> actually "syn

Re: [HACKERS] Fairly serious bug induced by latest guc enum changes

2008-07-01 Thread Tom Lane
Magnus Hagander <[EMAIL PROTECTED]> writes: > Or are you talking about changing the variable "fsync"? If so, doesn't > "fsync=off" also change the behavior of other parts of the code, so it's > not just WAL, which means it'd be pretty unsafe *anyway* unless you > actually "sync" the disks, and not

Re: [HACKERS] Access to localized_str_tolower()

2008-07-01 Thread David E. Wheeler
On Jul 1, 2008, at 11:59, Tom Lane wrote: These are static --- that's why you can't get at them from outside the module. I think your best bet for an 8.3 version of citext is just to copy-and-paste a lot of code from HEAD. Well, that's what I'd done already; I was just trying to make it sim

Re: [HACKERS] Location for pgstat.stat

2008-07-01 Thread Magnus Hagander
Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> writes: >> But pending that we have that, how about we just move it into it's own >> subdirectory? >> This would make it possible to symlink or mount that directory off to a >> ramdrive (for example). > > Hmm ... that would almost certainly res

Re: [HACKERS] Access to localized_str_tolower()

2008-07-01 Thread Tom Lane
"David E. Wheeler" <[EMAIL PROTECTED]> writes: > From formatting.c in 8.3.1: > static char *localized_str_toupper(char *buff); > static char *localized_str_tolower(char *buff); These are static --- that's why you can't get at them from outside the module. I think your best bet for an 8.3 version

Re: [HACKERS] Fairly serious bug induced by latest guc enum changes

2008-07-01 Thread Magnus Hagander
Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> writes: >> Tom Lane wrote: >>> Hmm ... or at least more or less fixed. Seems like there's no provision >>> to close and reopen the file if enableFsync changes. Not sure if that's >>> worth worrying about. > >> We didn't have that before eithe

Re: [HACKERS] Location for pgstat.stat

2008-07-01 Thread Tom Lane
Magnus Hagander <[EMAIL PROTECTED]> writes: > But pending that we have that, how about we just move it into it's own > subdirectory? > This would make it possible to symlink or mount that directory off to a > ramdrive (for example). Hmm ... that would almost certainly result in the stats being los

Re: [HACKERS] Fairly serious bug induced by latest guc enum changes

2008-07-01 Thread Tom Lane
Magnus Hagander <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Hmm ... or at least more or less fixed. Seems like there's no provision >> to close and reopen the file if enableFsync changes. Not sure if that's >> worth worrying about. > We didn't have that before either, did we? No, so I thin

[HACKERS] Location for pgstat.stat

2008-07-01 Thread Magnus Hagander
Per this thread: http://archives.postgresql.org/pgsql-general/2007-12/msg00255.php it was pretty much (again, IIRC) concluded that we want "some better way" to transfer the stats data. But pending that we have that, how about we just move it into it's own subdirectory? AFAICS that would be a simp

Re: [HACKERS] A new take on the foot-gun meme

2008-07-01 Thread Shane Ambler
Robert Treat wrote: So is that a "golf club gun"? Careful what you wish for http://www.totallyabsurd.com/12gaugegolfclub.htm I reckon they watched Caddyshack (I think that was the one) and thought they could get the patent before someone actually tried selling them. I reckon it wa

Re: [HACKERS] WIP patch: reducing overhead for repeat de-TOASTing

2008-07-01 Thread Tom Lane
[ back on-list ] Mark Cave-Ayland <[EMAIL PROTECTED]> writes: > Thanks very much for supplying the WIP patch. In the interest of testing > and feedback, I've just downloaded PostgreSQL CVS head and applied your > patch, compiled up a slightly modified version of PostGIS (without > RECHECKs on t

Re: [HACKERS] Access to localized_str_tolower()

2008-07-01 Thread Bruce Momjian
David E. Wheeler wrote: > On Jul 1, 2008, at 11:11, Bruce Momjian wrote: > > > That whole use of localized_* is gone in CVS HEAD --- we now have a > > cleaner API. > > I know. The patch I sent in uses it. However, I still have a version I > want to use on 8.3. So what would be the proper functi

Re: [HACKERS] triggers on prepare, commit, rollback... ?

2008-07-01 Thread Bruce Momjian
Andrew Dunstan wrote: > > > Fabien COELHO wrote: > > > > Dear Tom, > > > >>> trigger on "prepare", "commit", "rollback", "savepoint", > >> Yup, and there won't be. > > > > That's a definite answer! > > > >> This has been suggested and rejected before. See the archives. > > > > I'll check into th

Re: [HACKERS] Access to localized_str_tolower()

2008-07-01 Thread David E. Wheeler
On Jul 1, 2008, at 11:11, Bruce Momjian wrote: That whole use of localized_* is gone in CVS HEAD --- we now have a cleaner API. I know. The patch I sent in uses it. However, I still have a version I want to use on 8.3. So what would be the proper function to use in 8.3.x and how can I get

Re: [HACKERS] Access to localized_str_tolower()

2008-07-01 Thread Bruce Momjian
David E. Wheeler wrote: > On Jul 1, 2008, at 10:38, Bruce Momjian wrote: > > >> Oh, and on a side note, should I localized_str_tolower() or just > >> str_tolower()? > > > > I am not sure what localized_str_tolower() is but I think you should > > call str_tolower directly if you want to pass char*

Re: [PATCHES] [HACKERS] TRUNCATE TABLE with IDENTITY

2008-07-01 Thread Bruce Momjian
Alvaro Herrera wrote: > Tom Lane wrote: > > > 2. I had first dismissed Neil's idea of transactional sequence updates > > as impossible, but on second look it could be done. Suppose RESTART > > IDENTITY does this for each sequence; > > > > * obtain AccessExclusiveLock; > > * assign a new

Re: [HACKERS] Fairly serious bug induced by latest guc enum changes

2008-07-01 Thread Magnus Hagander
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: >> Tom Lane wrote: >>> No, my point was that there are three possible states of sync_bit and >>> your patch only accounted for transitions between two of 'em. > >> Did this every get addressed? I don't see a commit for it. > > I thought

Re: [HACKERS] Access to localized_str_tolower()

2008-07-01 Thread David E. Wheeler
On Jul 1, 2008, at 10:38, Bruce Momjian wrote: Oh, and on a side note, should I localized_str_tolower() or just str_tolower()? I am not sure what localized_str_tolower() is but I think you should call str_tolower directly if you want to pass char*, and lower() if you want to pass 'text'.

Re: [HACKERS] Access to localized_str_tolower()

2008-07-01 Thread Bruce Momjian
David E. Wheeler wrote: > Howdy, > > In my original implementation of citext, which I'm going to start > using for an app I'm developing, I pull in the wstring_lower function > from oracle_compat.c by simply declaring it at the top of citext.c, > just as if it were in an include file: > >

[HACKERS] Access to localized_str_tolower()

2008-07-01 Thread David E. Wheeler
Howdy, In my original implementation of citext, which I'm going to start using for an app I'm developing, I pull in the wstring_lower function from oracle_compat.c by simply declaring it at the top of citext.c, just as if it were in an include file: extern char * wstring_lower (char *s

Re: [HACKERS] PATCH: CITEXT 2.0

2008-07-01 Thread David E. Wheeler
On Jul 1, 2008, at 07:38, Tom Lane wrote: However, it will be solved when collation per column will be implemented. Well, yeah, but that seems a very long way off. In the meantime a lot of people use the existing pgfoundry citext module. And even more of us have written queries using LOWER

Re: [HACKERS] Latest on CITEXT 2.0

2008-07-01 Thread Marko Kreen
On 7/1/08, Tom Lane <[EMAIL PROTECTED]> wrote: > "Marko Kreen" <[EMAIL PROTECTED]> writes: > > ATM I'm looking at str_tolower/upper internal implementation. > > They do: > > workspace[curr_char] = towlower(workspace[curr_char]); > > where workspace is wchar_t but towlower() operates on wint_t.

Re: [HACKERS] Latest on CITEXT 2.0

2008-07-01 Thread Tom Lane
"Marko Kreen" <[EMAIL PROTECTED]> writes: > There's another thing I'm probably missing: does current code handle > multi-wchar codepoints? Or is it guaranteed they don't happen? AFAIK we disallow multi-wchar situations (by rejecting the UTF8 combining codes). > (Wasn't wchar_t usually 16bit valu

Re: [HACKERS] Latest on CITEXT 2.0

2008-07-01 Thread Tom Lane
"Marko Kreen" <[EMAIL PROTECTED]> writes: > ATM I'm looking at str_tolower/upper internal implementation. > They do: > workspace[curr_char] = towlower(workspace[curr_char]); > where workspace is wchar_t but towlower() operates on wint_t. IIRC this is exactly comparable to the type situation for

Re: [HACKERS] Latest on CITEXT 2.0

2008-07-01 Thread Marko Kreen
On 7/1/08, Bruce Momjian <[EMAIL PROTECTED]> wrote: > If you want a simple example of wide character use look at > oracle_compat.c::upper() which calls str_toupper() in CVS HEAD. ATM I'm looking at str_tolower/upper internal implementation. They do: workspace[curr_char] = towlower(workspace[c

Re: [HACKERS] Latest on CITEXT 2.0

2008-07-01 Thread Bruce Momjian
Marko Kreen wrote: > On 7/1/08, Tom Lane <[EMAIL PROTECTED]> wrote: > > "Marko Kreen" <[EMAIL PROTECTED]> writes: > > > On 6/26/08, Tom Lane <[EMAIL PROTECTED]> wrote: > > > > >> BTW, I don't think you can use that same-length optimization for > > >> citext. There's no reason to think that upper

Re: Does anything dump per-database config settings? (was Re: [HACKERS] ALTER DATABASE vs pg_dump)

2008-07-01 Thread Richard Huxton
Robert Treat wrote: On Tuesday 01 July 2008 03:45:44 Richard Huxton wrote: The only time we need to restore per-database settings is if the database has been dropped. If you're not having the dump/restore re-create the database then presumably you've taken charge of the per-database settings.

Re: [HACKERS] Latest on CITEXT 2.0

2008-07-01 Thread Marko Kreen
On 7/1/08, Tom Lane <[EMAIL PROTECTED]> wrote: > "Marko Kreen" <[EMAIL PROTECTED]> writes: > > On 6/26/08, Tom Lane <[EMAIL PROTECTED]> wrote: > > >> BTW, I don't think you can use that same-length optimization for > >> citext. There's no reason to think that upper/lowercase pairs will > >> hav

[HACKERS] [WIP] patch - Collation at database level

2008-07-01 Thread Radek Strnad
Hello, I'm sending part of the code that I've done and is available for reviewing and I'm asking for your comments and some help because I'm new to PostgreSQL. Proposal: http://archives.postgresql.org/pgsql-hackers/2008-05/msg00857.php The code contains changes of parser, pg_collation catalog, p

Re: [HACKERS] Latest on CITEXT 2.0

2008-07-01 Thread Tom Lane
"Marko Kreen" <[EMAIL PROTECTED]> writes: > On 6/26/08, Tom Lane <[EMAIL PROTECTED]> wrote: >> BTW, I don't think you can use that same-length optimization for >> citext. There's no reason to think that upper/lowercase pairs will >> have the same length all the time in multibyte encodings. > What

Re: [HACKERS] Latest on CITEXT 2.0

2008-07-01 Thread Marko Kreen
On 6/26/08, Tom Lane <[EMAIL PROTECTED]> wrote: > "David E. Wheeler" <[EMAIL PROTECTED]> writes: > > Datum citext_ne (PG_FUNCTION_ARGS) { > > // Fast path for different-length inputs. Okay for canonical > > equivalence? > > if (VARSIZE(PG_GETARG_TEXT_P(0)) != VARSIZE(PG_GETARG_TEXT_P(

Re: [HACKERS] PATCH: CITEXT 2.0

2008-07-01 Thread Tom Lane
Zdenek Kotala <[EMAIL PROTECTED]> writes: > However, it will be solved when collation per column will be implemented. Well, yeah, but that seems a very long way off. In the meantime a lot of people use the existing pgfoundry citext module. regards, tom lane -- Sent via

Re: [HACKERS] A new take on the foot-gun meme

2008-07-01 Thread Robert Treat
On Monday 30 June 2008 00:57:03 Tom Lane wrote: > [ after recovering from choking... ] > > Tom "spot" Callaway presents a vivid new image in this line: > > What you're doing is analogous to using a loaded shotgun as a golf club, > > and what you're suggesting is that we take the safety off, because

Re: [HACKERS] Dept of ugly hacks: eliminating padding space in system indexes

2008-07-01 Thread Zdenek Kotala
Tom Lane napsal(a): Zdenek Kotala <[EMAIL PROTECTED]> writes: Tom Lane napsal(a): Cutting a third off the size of a system index has got to be worth something, but is it worth a hack as ugly as this one? The problem what I see there is how to fit with in-place-upgrade. Catalog should be gene

Re: [HACKERS] PATCH: CITEXT 2.0

2008-07-01 Thread Zdenek Kotala
David E. Wheeler napsal(a): Howdy, Howdy, Please find attached a patch adding a locale-aware, case-insensitive text type, called citext, as a contrib module. A few notes: What is benefit to have this type when collation per database will be implemented? It seems to me that its overlappe

Re: [HACKERS] Confusing message in log file

2008-07-01 Thread Gurjeet Singh
On Mon, Jun 30, 2008 at 7:33 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > In any case, this seems a case of stuffing too much in the primary > > message. > > Yeah, good point. > > > I think it should be something like > > errmsg("parameter \"shared_buffe

Re: [HACKERS] Dept of ugly hacks: eliminating padding space in system indexes

2008-07-01 Thread Tom Lane
Zdenek Kotala <[EMAIL PROTECTED]> writes: > Tom Lane napsal(a): >> Cutting a third off the size of a system index has got to be worth >> something, but is it worth a hack as ugly as this one? > The problem what I see there is how to fit with in-place-upgrade. Catalog > should > be generate from

Re: [HACKERS] WIP patch: reducing overhead for repeat de-TOASTing

2008-07-01 Thread Tom Lane
Mark Cave-Ayland <[EMAIL PROTECTED]> writes: > Unfortunately I have to report back that with your WIP patch applied, > timings seem to have become several orders of magnitude *worse*: Ugh. Could I pester you to run the case under gprof or oprofile? Or, if you can give me step-by-step directions

Re: [HACKERS] Dept of ugly hacks: eliminating padding space in system indexes

2008-07-01 Thread Zdenek Kotala
Tom Lane napsal(a): Cutting a third off the size of a system index has got to be worth something, but is it worth a hack as ugly as this one? The problem what I see there is how to fit with in-place-upgrade. Catalog should be generate from scratch, but if somebody uses name in regular table

Re: [HACKERS] WIP patch: reducing overhead for repeat de-TOASTing

2008-07-01 Thread Mark Cave-Ayland
Guillaume Smet wrote: From the discussion we had a few months ago, I don't think the no RECHECK trick works with CVS tip anymore. See my post on the "Remove lossy-operator RECHECK flag?" thread: http://archives.postgresql.org/pgsql-hackers/2008-04/msg00847.php and follow-ups. That said, perhap

Re: [HACKERS] TODO assignment

2008-07-01 Thread Zdenek Kotala
Jiri Dvorak napsal(a): Hello I wish to ask, whether is somebody working on this TODO point: Look on this: http://archives.postgresql.org/pgsql-hackers/2008-04/msg00049.php --- GRANT/REVOKE * Allow column-level privileges * %Allow GRANT/REVOKE permissions to be applied

Re: Does anything dump per-database config settings? (was Re: [HACKERS] ALTER DATABASE vs pg_dump)

2008-07-01 Thread Robert Treat
On Tuesday 01 July 2008 03:45:44 Richard Huxton wrote: > Tom Lane wrote: > > Richard Huxton <[EMAIL PROTECTED]> writes: > >> Tom Lane wrote: > >>> So put forward a worked-out proposal for some other behavior. > >> > >> IMHO the time a dump/restore should be issuing ALTER...SET on a database > >> is

Re: [HACKERS] WIP patch: reducing overhead for repeat de-TOASTing

2008-07-01 Thread Guillaume Smet
Mark, On Tue, Jul 1, 2008 at 1:15 PM, Mark Cave-Ayland <[EMAIL PROTECTED]> wrote: > Thanks very much for supplying the WIP patch. In the interest of testing and > feedback, I've just downloaded PostgreSQL CVS head and applied your patch, > compiled up a slightly modified version of PostGIS (withou

Re: [HACKERS] WIP patch: reducing overhead for repeat de-TOASTing

2008-07-01 Thread Mark Cave-Ayland
Tom Lane wrote: Attached is a worked-out patch for the approach proposed here: http://archives.postgresql.org/pgsql-hackers/2008-06/msg00777.php namely, that cache management for de-TOASTed datums is handled by TupleTableSlots. To avoid premature detoasting of values that we might never need, th

Re: [HACKERS] Explain XML patch

2008-07-01 Thread Gregory Stark
I'm reading through the Explain XML patch. Just a couple of quick observations: There are a few whitespace oddities which like: switch (nodeTag(plan)) { case T_IndexScan: + { + StringInfo index; + index = m

Re: [HACKERS] Bucket and batch

2008-07-01 Thread Gregory Stark
"Tom Lane" <[EMAIL PROTECTED]> writes: > "Ana Carolina Brito de Almeida" <[EMAIL PROTECTED]> writes: >> So, I would like to know the differences between bucket and batch. > > A bucket is, well, one bucket of a hash table --- it holds all the > tuples that have the same hash code (for as many bits

Re: [HACKERS] Planned obsolescence in identify_system_timezone()

2008-07-01 Thread Gregory Stark
"Tom Lane" <[EMAIL PROTECTED]> writes: > I just noticed that identify_system_timezone() tries to match our > timezones to the system timezone on the basis of probing the date > range 1904-2004. While doubtless this seemed like a good idea at > the time, it means that we'll be unable to distinguis

Re: Does anything dump per-database config settings? (was Re: [HACKERS] ALTER DATABASE vs pg_dump)

2008-07-01 Thread Richard Huxton
Tom Lane wrote: Richard Huxton <[EMAIL PROTECTED]> writes: Tom Lane wrote: So put forward a worked-out proposal for some other behavior. IMHO the time a dump/restore should be issuing ALTER...SET on a database is when it has issued the corresponding CREATE DATABASE. So pg_dump would produc