Andrew Gierth writes:
> Note that I'm talking here about the names of the C functions, not
> the SQL names.
> The existing hstore has some very dubious choices of function names
> (for non-static functions) in the C code; functions like each(),
> delete(), fetchval(), defined(), tconvert(), etc.
Robert Haas wrote:
> I personally think that the way pgsql-hackers organizes itself using
> email is completely insane. The only reason that you need to write
> the release notes instead of, say, me, is because the only information
> on what needs to go into them is buried in a thicket of CVS comm
Alvaro Herrera wrote:
> Bruce Momjian escribi?:
> > Alvaro Herrera wrote:
>
> > > Note that during the 8.4 timeframe we've stolen a lot of work from
> > > Bruce. The TODO list was moved to the wiki, for one; the "patch queue"
> > > was also moved to the wiki. Now the FAQ has moved to wiki (and h
On Fri, Mar 20, 2009 at 9:57 PM, Andrew Gierth
wrote:
> Note that I'm talking here about the names of the C functions, not
> the SQL names.
>
> The existing hstore has some very dubious choices of function names
> (for non-static functions) in the C code; functions like each(),
> delete(), fetchva
The estimation functions assume the inner relation join column is
unique. But it freezes (flushes back to the main hash table) one skew
bucket at a time in order of least importance so if 100 inner tuples
can fit in the skew buckets then the skew buckets are only fully blown
out if the best tuple
Note that I'm talking here about the names of the C functions, not
the SQL names.
The existing hstore has some very dubious choices of function names
(for non-static functions) in the C code; functions like each(),
delete(), fetchval(), defined(), tconvert(), etc. which all look to me
like prime c
Not necessarily true. Seeing as (when the statistics are correct) we
know each of these inner tuples will match with the largest amount of
outer tuples it is just as much of a win per inner tuple as when they
are unique. There is just a chance you will have to give up on the
optimization part way
On Fri, Mar 20, 2009 at 8:45 PM, Bryce Cutt wrote:
> On Fri, Mar 20, 2009 at 5:35 PM, Robert Haas wrote:
>> If the inner relation isn't fairly close to unique you shouldn't be
>> using this optimization in the first place.
> Not necessarily true. Seeing as (when the statistics are correct) we
>
On Fri, Mar 20, 2009 at 8:45 PM, Bryce Cutt wrote:
> On Fri, Mar 20, 2009 at 5:35 PM, Robert Haas wrote:
>> If the inner relation isn't fairly close to unique you shouldn't be
>> using this optimization in the first place.
> Not necessarily true. Seeing as (when the statistics are correct) we
>
On Fri, Mar 20, 2009 at 8:14 PM, Tom Lane wrote:
> Bryce Cutt writes:
>> Here is the new patch.
>
> Applied with revisions. I undid some of the "optimizations" that
> cluttered the code in order to save a cycle or two per tuple --- as per
> previous discussion, that's not what the performance qu
Here's an attempt. Let me know what you think. I had thought to
maybe just write a script to generate Mediawiki output and then post
it on the wiki where anyone could edit it. But that's not going to
work if you're going to continue adding to this, or at least not
without more thought about how
Bryce Cutt writes:
> Here is the new patch.
Applied with revisions. I undid some of the "optimizations" that
cluttered the code in order to save a cycle or two per tuple --- as per
previous discussion, that's not what the performance questions were
about. Also, I did not like the terminology "i
Sergey Burladyan writes:
> gettext-plural-ru-test.patch:
> - correct translation for "1 rows" message
hmmm... encoding is broken... i post it again in gzip
gettext-plural-ru-test.patch.gz
Description: gettext-plural-ru-test.patch
--
Sergey Burladyan
--
Sent via pgsql-hackers mailing l
On Mar 20, 2009, at 8:56 AM, Andrew Dunstan wrote:
Andrew Dunstan wrote:
A "/" at the beginning of a path expression is an abbreviation for
the initial step fn:root(self::node()) treat as document-node()/
(however, if the "/" is the entire path expression, the trailing
"/"
is omitted
Alvaro Herrera writes:
> Care to submit a patch?
this is it, i divide it into two, first is change source and second is change
ru.po file for psql.
changelog:
gettext-plural-test.patch
- check ngettext in configure (HAVE_NGETTEXT), show warning if not. must be
error, i agree with Peter, i t
On 3/20/09, Bruce Momjian wrote:
> Here are some of the emails I consider open for 8.4:
>
>http://momjian.us/cgi-bin/pgsql/open
>
Item #3 Extending grant insert on tables to sequences
is not for 8.4, i haven't reviewed it to adjust the patch after column
privileges was applied. i will up
On Fri, Mar 20, 2009 at 1:40 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> I don't even understand why we're interested in doing this. If the
>> patches weren't important enough for someone to add them to the
>> CommitFest wiki in October, why are we delaying the release to hunt
>> for the
Hello
I am sending samples of possible future modules based on transformationHook
regards
Pavel Stehule
tmodules.tgz
Description: GNU Zip compressed data
*** ./src/backend/parser/parse_expr.c.orig 2009-03-17 16:20:18.0 +0100
--- ./src/backend/parser/parse_expr.c 2009-03-17 16:24:43.
Merlin Moncure wrote:
> On Fri, Mar 20, 2009 at 4:08 PM, Bruce Momjian wrote:
> > Bruce Momjian wrote:
> >> Bruce Momjian wrote:
> >> > Here are some of the emails I consider open for 8.4:
> >> >
> >> > ? ? http://momjian.us/cgi-bin/pgsql/open
> >> >
> >> > (Same email, using updated subject line.
On Fri, Mar 20, 2009 at 4:08 PM, Bruce Momjian wrote:
> Bruce Momjian wrote:
>> Bruce Momjian wrote:
>> > Here are some of the emails I consider open for 8.4:
>> >
>> > http://momjian.us/cgi-bin/pgsql/open
>> >
>> > (Same email, using updated subject line.)
>>
>> mbox download URL fixed.
>
> L
> "Josh" == Josh Berkus writes:
> Tom Lane wrote:
>> Josh Berkus writes:
>>> As an hstore user, I'd be fine with simply limiting it to 64K (or,
>>> heck, 8K) and throwing an error. I'd also be fine with limiting
>>> keys to 255 bytes, although we'd have to warn people.
>> Yeah, 255 mi
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Here are some of the emails I consider open for 8.4:
> >
> > http://momjian.us/cgi-bin/pgsql/open
> >
> > (Same email, using updated subject line.)
>
> mbox download URL fixed.
Let me add that my item tracking is more of a blob that expands an
On Fri, Mar 20, 2009 at 4:06 PM, Joshua D. Drake wrote:
> On Fri, 2009-03-20 at 16:03 -0400, Robert Haas wrote:
>> On Fri, Mar 20, 2009 at 4:03 PM, Bruce Momjian wrote:
>> > Robert Haas wrote:
>> >> On Fri, Mar 20, 2009 at 3:50 PM, Bruce Momjian wrote:
>> >> > You can use my emails to make a mas
On Fri, 2009-03-20 at 16:03 -0400, Robert Haas wrote:
> On Fri, Mar 20, 2009 at 4:03 PM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> On Fri, Mar 20, 2009 at 3:50 PM, Bruce Momjian wrote:
> >> > You can use my emails to make a master list --- there is no need to make
> >> > mine the master.
>
Bruce Momjian wrote:
> Here are some of the emails I consider open for 8.4:
>
> http://momjian.us/cgi-bin/pgsql/open
>
> (Same email, using updated subject line.)
mbox download URL fixed.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://ente
Here are some of the emails I consider open for 8.4:
http://momjian.us/cgi-bin/pgsql/open
(Same email, using updated subject line.)
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ
On Fri, Mar 20, 2009 at 4:03 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Fri, Mar 20, 2009 at 3:50 PM, Bruce Momjian wrote:
>> > You can use my emails to make a master list --- there is no need to make
>> > mine the master.
>>
>> OK, good enough. Can you post a link to the raw mbox file?
Robert Haas wrote:
> On Fri, Mar 20, 2009 at 3:50 PM, Bruce Momjian wrote:
> > You can use my emails to make a master list --- there is no need to make
> > mine the master.
>
> OK, good enough. Can you post a link to the raw mbox file?
OK, done:
http://momjian.us/cgi-bin/pgsql/open
--
On Fri, Mar 20, 2009 at 3:50 PM, Bruce Momjian wrote:
> You can use my emails to make a master list --- there is no need to make
> mine the master.
OK, good enough. Can you post a link to the raw mbox file?
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
Robert Haas wrote:
> On Fri, Mar 20, 2009 at 3:23 PM, Bruce Momjian wrote:
> > I did offer to post my mbox file so people could see what I have as open
> > 8.4 items, but the "no complaining" requirement seems to have eliminated
> > volunteers.
>
> IIRC, the biggest problem we had last time (apar
On Fri, Mar 20, 2009 at 3:23 PM, Bruce Momjian wrote:
> I did offer to post my mbox file so people could see what I have as open
> 8.4 items, but the "no complaining" requirement seems to have eliminated
> volunteers.
IIRC, the biggest problem we had last time (apart from the
complaining) was tha
Robert Haas wrote:
> >> Of course, if this list is radically incomplete, then it doesn't help
> >> much, but does anyone think that's the case?
> >
> > We don't know -- Bruce's list may contain something, but since it's
> > hidden we can't do anything. ?Maybe it is all already-completed items,
> >
On Fri, Mar 20, 2009 at 3:13 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Fri, Mar 20, 2009 at 1:40 PM, Alvaro Herrera
>> wrote:
>> > Robert Haas escribió:
>> >> I don't even understand why we're interested in doing this. If the
>> >> patches weren't important enough for someone to ad
Robert Haas escribió:
> On Fri, Mar 20, 2009 at 1:40 PM, Alvaro Herrera
> wrote:
> > Robert Haas escribió:
> >> I don't even understand why we're interested in doing this. If the
> >> patches weren't important enough for someone to add them to the
> >> CommitFest wiki in October, why are we delay
On Fri, Mar 20, 2009 at 1:10 PM, Bruce Momjian wrote:
> This is about the reaction I expected, and is again so far off the mark
> that I will just continue doing what I think is best.
Would you like to explain WHY it's off the mark?
> Why doesn't someone offer to take my mbox file and generate a
Robert Haas escribió:
> I don't even understand why we're interested in doing this. If the
> patches weren't important enough for someone to add them to the
> CommitFest wiki in October, why are we delaying the release to hunt
> for them in March?
The problem is not patches that were not committ
On Fri, Mar 20, 2009 at 1:08 PM, Alvaro Herrera
wrote:
>> I personally think that the way pgsql-hackers organizes itself using
>> email is completely insane.
> Note that during the 8.4 timeframe we've stolen a lot of work from
> Bruce. The TODO list was moved to the wiki, for one; the "patch queu
On Fri, Mar 20, 2009 at 1:08 PM, Heikki Linnakangas
wrote:
> The TODO list is already on the Wiki. I've edited it a few times when I've
> spotted TODO-worthy ideas on the mailing lists.
Well, Bruce and Tom both made reference to something that Bruce was
going to produce along these lines... I th
Alvaro Herrera wrote:
> Bruce Momjian escribi?:
> > Alvaro Herrera wrote:
> > > Bruce Momjian escribi?:
>
> > > > > We do have an alternative "open items" list,
> > > > > http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items
> > > > > However, it's incomplete. It is a bit sad that nobody can
Bruce Momjian escribió:
> Alvaro Herrera wrote:
> > Bruce Momjian escribi?:
> > > > We do have an alternative "open items" list,
> > > > http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items
> > > > However, it's incomplete. It is a bit sad that nobody can complete it,
> > > > because Bruce h
Alvaro Herrera wrote:
> Bruce Momjian escribi?:
> > Alvaro Herrera wrote:
>
> > > Note that during the 8.4 timeframe we've stolen a lot of work from
> > > Bruce. The TODO list was moved to the wiki, for one; the "patch queue"
> > > was also moved to the wiki. Now the FAQ has moved to wiki (and h
Bruce Momjian escribió:
> Alvaro Herrera wrote:
> > Note that during the 8.4 timeframe we've stolen a lot of work from
> > Bruce. The TODO list was moved to the wiki, for one; the "patch queue"
> > was also moved to the wiki. Now the FAQ has moved to wiki (and has
> > already seen lots of improv
Alvaro Herrera wrote:
> Robert Haas escribi?:
>
> > I personally think that the way pgsql-hackers organizes itself using
> > email is completely insane.
>
> Note that during the 8.4 timeframe we've stolen a lot of work from
> Bruce. The TODO list was moved to the wiki, for one; the "patch queue"
This is about the reaction I expected, and is again so far off the mark
that I will just continue doing what I think is best.
Why doesn't someone offer to take my mbox file and generate a list from
that?
---
Robert Haas wro
Robert Haas escribió:
> I personally think that the way pgsql-hackers organizes itself using
> email is completely insane.
Note that during the 8.4 timeframe we've stolen a lot of work from
Bruce. The TODO list was moved to the wiki, for one; the "patch queue"
was also moved to the wiki. Now th
Robert Haas wrote:
Similarly, the only reason we don't have a workable TODO list is
because you're attempting to extract it from a disorganized jumble of
email after the fact, instead of maintaining it publicly and adding
and removing items along the way. It might be slightly more work to
think
On Fri, Mar 20, 2009 at 10:34 AM, Bruce Momjian wrote:
> Robert Treat wrote:
>> On Tuesday 17 March 2009 09:38:59 Bruce Momjian wrote:
>> > You are assuming that only commit-fest work is required to get us to
>> > beta. You might remember the long list of open items I faced in January
>> > that I
Andrew Dunstan wrote:
Hannu Krosing wrote:
Is it just that in you _can't_ use Xpath on fragments, and you _need_ to
pass full documents to Xpath ?
At least this is my reading of Xpath standard.
I think that's possibly overstating it., unless I have missed
something (W3 standards are s
Bruce Momjian writes:
> Robert Treat wrote:
>> ... Perhaps we
>> need to take a fresh look at your list of twenty things and see what can be
>> delegated out to others.
> Yep, I agree. The problem is that last time I put out a list that
> wasn't clensed I got a lot of compaints so I am only g
Peter Eisentraut píše v pá 20. 03. 2009 v 15:33 +0200:
> (Hmm, no one except Zdenek testing locales yet on the build farm? Can't
> easily tell from the index page.)
It seems to me like good idea to add column with locale list tested on a
animal.
Zdenek
--
Sent via pgsql-hackers mai
On Tue, Mar 17, 2009 at 09:38:59AM -0400, Bruce Momjian wrote:
> Robert Haas wrote:
> > > Well, we have been working on stuff for the past month so it was not
> > > like we were waiting on SE-PG to move forward.
> >
> > Stuff related to the CommitFest?
> >
> > AFAICS, the only committer who has d
Robert Treat wrote:
> On Tuesday 17 March 2009 09:38:59 Bruce Momjian wrote:
> > You are assuming that only commit-fest work is required to get us to
> > beta. You might remember the long list of open items I faced in January
> > that I have whittled down, but I still have about twenty left.
> >
>
Peter Eisentraut wrote:
Tom Lane wrote:
It's still broken:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gothic_moth&dt=2009-03-17%2021:06:01
I remain of the opinion that supporting the regression tests in a locale
that works like this is more trouble than it's worth.
We looked into
Tom Lane wrote:
It's still broken:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gothic_moth&dt=2009-03-17%2021:06:01
I remain of the opinion that supporting the regression tests in a locale
that works like this is more trouble than it's worth.
We looked into this and it turns out that thi
On Tuesday 17 March 2009 09:38:59 Bruce Momjian wrote:
> You are assuming that only commit-fest work is required to get us to
> beta. You might remember the long list of open items I faced in January
> that I have whittled down, but I still have about twenty left.
>
I think part of the perception
Hi All,
Some brief information about the thick index patch.
The patch adds snapshot (MVCC) information to the indexes to enable them
being used independently. With this information, the indexes need not refer
to the heap data to check an index key's visibility. Various functions such
as IndexTup
Gokulakannan Somasundaram wrote:
It would be helpful to explain how this solves the lack of atomicity of
visibility data updates, which last time I checked was the killer
problem for this feature.
Hmmm... To put it more clearly, this problem occurs when there is a thick
index on a mutable funct
Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
This one is very basic, it just shows the child tables of a specific
table when you type \d in psql :
I'm not so jazzed about this, as I work on systems that have literally
hundreds of child tables.
hi everyone.
> It would be helpful to explain how this solves the lack of atomicity of
> visibility data updates, which last time I checked was the killer
> problem for this feature.
>
Hmmm... To put it more clearly, this problem occurs when there is a thick
index on a mutable function(marked as immutable). In
59 matches
Mail list logo
