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
>
"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
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
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
-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
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
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
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,
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,
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
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
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
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
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
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
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
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
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,
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
"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
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
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
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
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
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
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
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
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
"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
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
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
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
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
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
[ 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
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
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
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
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*
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
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
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'.
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:
>
>
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
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
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.
"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
"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
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
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
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.
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
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
"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
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(
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 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
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
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
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
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
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
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
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
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
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
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
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
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
"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
"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
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
72 matches
Mail list logo
