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 produce
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 distinguish zones
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 of the hash
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 =
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,
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 (without
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 when it has issued
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
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, perhaps
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
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 for
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 scratch,
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_buffer\ change in
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
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
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 it
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
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(1)))
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 about this
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,
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
have the same length
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.
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/lowercase pairs will
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] =
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 the
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 value?)
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.
IIRC this
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
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
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:
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'.
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 it got fixed
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 relfilenode;
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*, and lower()
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
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 that.
This is a sufficiently
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 function to
[ 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 the
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 was
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
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 think it's a
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 lost
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 either, did we?
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 of
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 result in the
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
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 just fsync?
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 sync the disks,
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 is
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 expect
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 still be the
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 processed
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 before someone actually
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 database
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,
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 affected, but it
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
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:
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 wiki
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 alternative
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 June
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
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
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
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 they
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 reckon they watched Caddyshack (I think that
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
-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
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.3
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
70 matches
Mail list logo
