On Thursday 02 July 2009 05:29:58 Robert Haas wrote:
> If you are taking a look at
> any of the patches submitted for this CommitFest, please put your name
> next to them on the wiki. Please ALSO add a comment saying something
> like "tgl says: I am reviewing this, no need to assign a round-robin
On Wed, Jul 1, 2009 at 11:42 PM, Andrew Dunstan wrote:
> You have correctly identified the requirement in the sentence quoted above.
> I for one am quite prepared to support core or some person designated by
> core having such authority. I agree with you that without something like
> that not much
Tom Lane wrote:
Ron Mayer writes:
Bruce Momjian wrote:
Where did you see 8.4 was scheduled to be released around the start of
the year? I never never seen that and would have disputed anyone saying
it publicly.
I think people carefully avoided the word "scheduled", but the
press FAQ on www
Hi,
On Thu, Jul 2, 2009 at 5:19 AM, Lorraine Mancuso wrote:
> I am currently running PG version 8.3.1. I am working in a test
> environment. I have a situation where the WAL file needed at startup no
> longer exists and I really don't care about it, therefore, I just want to
> reset the logs an
2009/7/2 Robert Haas :
> The main problem is that my fine software only contains test data at
> this point. If we have any volunteers who are available to migrate
> the information from the Wiki to my app (which will involve a fair
> amount of legwork),
As the original author of the CF wiki templ
On Wed, Jul 1, 2009 at 8:21 PM, Josh Berkus wrote:
> There's been a lot of discussion/argument around how to handle the last
> commitfest, but there seems to be a total consensus that we want to have the
> first CF on July 15th.
>
> I'd like Robert Haas to be the CF Manager for that commitfest if h
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Bruce Momjian writes:
> >>> If we review patches as soon as they appear, and give rapid feedback, we
> >>> can easily reject patches that take more than a few days for the patch
> >>> author to resolve, and there would be little sli
Bruce Momjian writes:
> Tom Lane wrote:
>> Bruce Momjian writes:
>>> If we review patches as soon as they appear, and give rapid feedback, we
>>> can easily reject patches that take more than a few days for the patch
>>> author to resolve, and there would be little slippage; the same goes
>>> fo
On Wed, Jul 1, 2009 at 7:00 PM, Tom Lane wrote:
> Greg Stark writes:
>> On Tue, Jun 30, 2009 at 5:11 PM, Tom Lane wrote:
>>> I'm also not prepared to push a large and unstable feature into the tree
>>> on the hope that it will get fixed.
>
>> I didn't have the impression it had any known problems,
Tom Lane wrote:
> Bruce Momjian writes:
> > There has been discussion about how to be more hard-nosed about
> > rejecting patches. I think it has to start with us being more
> > hard-nosed about giving patches feedback --- the very idea we had to
> > create commit-fests reflects that we historica
Robert Haas wrote:
> > If we review patches as soon as they appear, and give rapid feedback, we
> > can easily reject patches that take more than a few days for the patch
> > author to resolve, and there would be little slippage; ?the same goes
> > for dealing with known bugs. ?I know it can be don
On Wed, Jul 1, 2009 at 7:30 PM, Tom Lane wrote:
> Let the breakage begin ...
>
> regards, tom lane
Tom - and all other committers -
In order to avoid duplication of effort, we should avoid assigning
round-robin reviewers to any patches which the committers feel that
they al
Bruce Momjian writes:
> There has been discussion about how to be more hard-nosed about
> rejecting patches. I think it has to start with us being more
> hard-nosed about giving patches feedback --- the very idea we had to
> create commit-fests reflects that we historically have not done an
> org
"Fly.Li" writes:
> 1 ginarrayextract() has 2 parameters
> 2 gin_extract_tsquery() has 3 parameters
> 3 run sql(from plsql/src/test/regress/sql/opr_sanity.sql), it expect no
> results:
Well, actually what's cheating here is ginarrayextract, not tsearch2.
That was fixed as of 8.3.
On Wed, Jul 1, 2009 at 6:55 PM, Bruce Momjian wrote:
> bruce wrote:
>> I realize there is the perception that the large patches that were
>> eventually rejected held up the release, but for all the patches I can
>> think of, they were not rejected immediately _because_ we had other
>> valid patches
1 ginarrayextract() has 2 parameters
2 gin_extract_tsquery() has 3 parameters
3 run sql(from plsql/src/test/regress/sql/opr_sanity.sql), it expect no
results:
-
SELECT p1.amopclaid, p1.amprocnum,
p2.oid, p2.proname,
p3.opcname,
p4.amopclaid, p4.amprocnum,
p5.oid, p5.proname,
p6.op
Tom Lane wrote:
> Joshua Tolley writes:
> > On Mon, Jun 29, 2009 at 02:07:23PM -0400, Tom Lane wrote:
> >> I think this is pretty much nonsense --- most queries run all their plan
> >> nodes concurrently to some extent. You can't usefully say that a query
> >> is "on" some node, nor measure progr
On Thu, Jul 2, 2009 at 1:25 AM, Tom Lane wrote:
>
> Hmm, 8.3 doesn't seem to recognize the syntax:
>
> regression=# alter table c add inherit p;
> ERROR: type "p" does not exist
> LINE 1: alter table c add inherit p;
> ^
Oh I remember being caught by this myself.
Incidentally there *is* a single-byte integer data type in Postgres,
it's called "char" (the quote marks are necessary in SQL due to the
char(n) data type).
It's a bit weird though, mainly because its output format is to output
ascii characters -- kind of like how C's single-byte integer data type
Greg Stark writes:
> On Wed, Jul 1, 2009 at 11:36 PM, Tom Lane wrote:
>> Comments?
> Uhm, we've had ADD INHERIT since 8.2 -- that was my first patch.
Hmm, 8.3 doesn't seem to recognize the syntax:
regression=# alter table c add inherit p;
ERROR: type "p" does not exist
LINE 1: alter table c ad
Folks,
There's been a lot of discussion/argument around how to handle the last
commitfest, but there seems to be a total consensus that we want to have
the first CF on July 15th.
I'd like Robert Haas to be the CF Manager for that commitfest if he's
available. I can help by running RRR or so
On Wed, Jul 1, 2009 at 11:36 PM, Tom Lane wrote:
> (It's a good thing we added ADD INHERIT in 8.4, or we'd be completely
> up the creek here.) In this way we can ensure that the physical order
> of columns really is what it needs to be in the child table. Dropped
> columns can then be managed in
I could find one more issue when we apply largeobject-style interfaces
on generic toasted varlena data.
When we fetch a toasted datum, it scans the pg_toast_%u with SnapshotToast,
because it assumes any toasted chunks don't have multiple versions, and
visibility of the toast pointer always means v
On Wed, Jul 1, 2009 at 6:53 PM, Kevin
Grittner wrote:
> Bruce Momjian wrote:
>
>> The problem is that the committers control the commit date, but the
>> one seen as punished for a rejected patch is not the committers but
>> the submitter.
>
> Well, it would seem odd for anyone to feel "punished".
Let the breakage begin ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Greg Stark writes:
> On Tue, Jun 30, 2009 at 5:11 PM, Tom Lane wrote:
>> I'm also not prepared to push a large and unstable feature into the tree
>> on the hope that it will get fixed.
> I didn't have the impression it had any known problems, Simon and
> others spent a lot of time testing it alre
Greg Stark wrote:
> On Tue, Jun 30, 2009 at 5:11 PM, Tom Lane wrote:
>
> > I'm also not prepared to push a large and unstable feature into the tree
> > on the hope that it will get fixed.
>
> I didn't have the impression it had any known problems, Simon and
> others spent a lot of time testing it
bruce wrote:
> I realize there is the perception that the large patches that were
> eventually rejected held up the release, but for all the patches I can
> think of, they were not rejected immediately _because_ we had other
> valid patches to work on. Once all valid patches were applied, we were
Bruce Momjian wrote:
> The problem is that the committers control the commit date, but the
> one seen as punished for a rejected patch is not the committers but
> the submitter.
Well, it would seem odd for anyone to feel "punished".
If the patch isn't submitted in good form with the issues h
I was testing pg_migrator the other day on the regression database,
and found out that it doesn't work:
Restoring database schema
psql:/home/postgres/pg_migrator_dump_db.sql:4545: ERROR: column
"pg.dropped.1" of relation "dropcolumnchild" does n
On Tue, Jun 30, 2009 at 5:11 PM, Tom Lane wrote:
> I'm also not prepared to push a large and unstable feature into the tree
> on the hope that it will get fixed.
I didn't have the impression it had any known problems, Simon and
others spent a lot of time testing it already. The improvements Heikk
Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > Define "make that date"? That is the problem.
>
> Not committed by that date. I guess that leaves the issue of picking
> a particular time in a particular time zone, but it doesn't otherwise
> seem ambiguous.
>
> Picture the New York Subw
Bruce Momjian wrote:
> Define "make that date"? That is the problem.
Not committed by that date. I guess that leaves the issue of picking
a particular time in a particular time zone, but it doesn't otherwise
seem ambiguous.
Picture the New York Subway system. You're coming down the stair
On Wed, Jul 1, 2009 at 5:01 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> Kevin Grittner wrote:
>>> However, even the *possibility* that this could be true is pretty
>>> scary. If we need to effectively shut down new development for seven
>>> months at the end of a release, in addition to the in
Tom Lane wrote:
"Joshua D. Drake" writes:
On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote:
It comes down to somebody having the willingness to say "no" and the
authority to make it stick. Robert mentioned upthread that the
committers don't want to be seen as throwing their weight
Joshua D. Drake wrote:
> On Wed, 2009-07-01 at 17:13 -0400, Tom Lane wrote:
> > "Joshua D. Drake" writes:
> > > On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote:
> > >> It comes down to somebody having the willingness to say "no" and the
> > >> authority to make it stick. Robert mentioned upthre
On Wed, 2009-07-01 at 17:13 -0400, Tom Lane wrote:
> "Joshua D. Drake" writes:
> > On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote:
> >> It comes down to somebody having the willingness to say "no" and the
> >> authority to make it stick. Robert mentioned upthread that the
> >> committers don't
"Joshua D. Drake" writes:
> On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote:
>> It comes down to somebody having the willingness to say "no" and the
>> authority to make it stick. Robert mentioned upthread that the
>> committers don't want to be seen as throwing their weight around,
> Is that
On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote:
> It comes down to somebody having the willingness to say "no" and the
> authority to make it stick. Robert mentioned upthread that the
> committers don't want to be seen as throwing their weight around,
Is that the purpose of core? To make exac
Bruce Momjian writes:
> Kevin Grittner wrote:
>> However, even the *possibility* that this could be true is pretty
>> scary. If we need to effectively shut down new development for seven
>> months at the end of a release, in addition to the interim commit
>> fests, we'd better get a handle on why
Lorraine Mancuso wrote:
> Hi,
>
> I am currently running PG version 8.3.1. I am working in a test
> environment. I have a situation where the WAL file needed at startup no
> longer exists and I really don't care about it,
This is never true -- if you lose a WAL file, there is potential
corru
Hi,
I am currently running PG version 8.3.1. I am working in a test
environment. I have a situation where the WAL file needed at startup no
longer exists and I really don't care about it, therefore, I just want
to reset the logs and go from there. However, after the pg_resetxlog, PG
is stil
On Jul 1, 2009, at 11:47 AM, Merlin Moncure wrote:
fyi: works in 8.4, as part of a broad fix of composite type
comparison ops
whoops, you knew that already :-). one possible workaround is:
select $1::text is distinct from $2::text
Yes, and that's what I'm doing, although it is significant
Kevin Grittner wrote:
> Bruce Momjian wrote:
> > The beta preparation is dealing with all open issues, which is
> > different than the focus of the commit-fest. Ideally we would be
> > addressing those open/bug issues during normal development, but for
> > the hard problems seem to linger and th
On Wed, Jul 1, 2009 at 2:45 PM, Merlin Moncure wrote:
> On Wed, Jul 1, 2009 at 1:35 PM, David E. Wheeler wrote:
>> This code:
>>
>> CREATE OR REPLACE FUNCTION foo() returns boolean as $$
>> DECLARE
>> have_rec record;
>> want_rec record;
>> BEGIN
>> have_rec := row(1,
On Wed, Jul 1, 2009 at 1:35 PM, David E. Wheeler wrote:
> This code:
>
> CREATE OR REPLACE FUNCTION foo() returns boolean as $$
> DECLARE
> have_rec record;
> want_rec record;
> BEGIN
> have_rec := row(1, 2);
> want_rec := row(3, 5);
> RETURN have_rec IS
Bruce Momjian wrote:
> The beta preparation is dealing with all open issues, which is
> different than the focus of the commit-fest. Ideally we would be
> addressing those open/bug issues during normal development, but for
> the hard problems seem to linger and then we have to deal with them
> d
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> In retrospect, the CF idea took some of the edge off the problem of
> >> lots of large patches arriving at the feature freeze deadline, but it
> >> is far from having eliminated the problem.
>
> > The beta preparation is dealing wit
Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > How could we have possibly completed the last commit-fest and gotten
> > ready for beta in two months --- that is just not realistic. I
> > think we anticipated a 2x longer final commit-fest, two months, but
> > there was no time scheduled for
Bruce Momjian writes:
> Tom Lane wrote:
>> In retrospect, the CF idea took some of the edge off the problem of
>> lots of large patches arriving at the feature freeze deadline, but it
>> is far from having eliminated the problem.
> The beta preparation is dealing with all open issues, which is di
Tom Lane wrote:
> Bruce Momjian writes:
> > OK, that is more accurate, but looking at the schedule:
>
> > 1st November 2008 - final commit fest begins
> > 1st January 2009 - beta 1
> > 1st March 2009 - 8.4.0 release
>
> > How could we have possibly completed the last commit-fest and
Ron Mayer writes:
> Bruce Momjian wrote:
>> Where did you see 8.4 was scheduled to be released around the start of
>> the year? I never never seen that and would have disputed anyone saying
>> it publicly.
> I think people carefully avoided the word "scheduled", but the
> press FAQ on www.postgr
Bruce Momjian wrote:
> How could we have possibly completed the last commit-fest and gotten
> ready for beta in two months --- that is just not realistic. I
> think we anticipated a 2x longer final commit-fest, two months, but
> there was no time scheduled for actual beta preparation.
For my
Ron Mayer wrote:
> Bruce Momjian wrote:
> > Where did you see 8.4 was scheduled to be released around the start of
> > the year? I never never seen that and would have disputed anyone saying
> > it publicly.
>
> I think people carefully avoided the word "scheduled", but the
> press FAQ on www.pos
Bruce Momjian writes:
> OK, that is more accurate, but looking at the schedule:
> 1st November 2008 - final commit fest begins
> 1st January 2009 - beta 1
> 1st March 2009 - 8.4.0 release
> How could we have possibly completed the last commit-fest and gotten
> ready for beta in
Bruce Momjian wrote:
Where did you see 8.4 was scheduled to be released around the start of
the year? I never never seen that and would have disputed anyone saying
it publicly.
I think people carefully avoided the word "scheduled", but the
press FAQ on www.postgresql.org did say to expect it i
Kevin Grittner wrote:
> Tom Lane wrote:
> > "Kevin Grittner" writes:
> >> That showed a January 1 beta release and a March 1 production
> >> release.
> >
> > Terminological problem. Around here, "release" *always* means
> > production release. We don't expect end users to be very interested
>
Kevin Grittner wrote:
> "Joshua D. Drake" wrote:
> > On Wed, 2009-07-01 at 12:47 -0500, Kevin Grittner wrote:
>
> >> http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php
> >>
> >> That showed a January 1 beta release and a March 1 production
> >> release.
> >
> > Right that woul
Tom Lane wrote:
> "Kevin Grittner" writes:
>> That showed a January 1 beta release and a March 1 production
>> release.
>
> Terminological problem. Around here, "release" *always* means
> production release. We don't expect end users to be very interested
> in pre-production versions.
Well,
"Kevin Grittner" writes:
> Bruce Momjian wrote:
>> Where did you see 8.4 was scheduled to be released around the start of
>> the year?
> http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php
> That showed a January 1 beta release and a March 1 production release.
Terminological pr
"Joshua D. Drake" wrote:
> On Wed, 2009-07-01 at 12:47 -0500, Kevin Grittner wrote:
>> http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php
>>
>> That showed a January 1 beta release and a March 1 production
>> release.
>
> Right that would be the expectation I had.
The first
On Wed, 2009-07-01 at 12:47 -0500, Kevin Grittner wrote:
> Bruce Momjian wrote:
> > Where did you see 8.4 was scheduled to be released around the start
> of
> > the year? I never never seen that and would have disputed anyone
> saying
> > it publicly.
>
> http://archives.postgresql.org/pgsql-h
Bruce Momjian wrote:
> Where did you see 8.4 was scheduled to be released around the start
of
> the year? I never never seen that and would have disputed anyone
saying
> it publicly.
http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php
That showed a January 1 beta release and a
On Wed, 2009-07-01 at 13:39 -0400, Bruce Momjian wrote:
> Where did you see 8.4 was scheduled to be released around the start of
> the year? I never never seen that and would have disputed anyone saying
> it publicly.
As I understood it, 8.4 was supposed to released at the beginning of Q2.
I nev
Kevin Grittner wrote:
> Ron Mayer wrote:
>
> > I could imagine an enterprise plan that says "we'll upgrade to
> > the current production release in January [after christmas sales]";
> > or "we'll begin to upgrade the January after [feature-x] is in
> > production".
> >
> > But in neither case
Ron Mayer writes:
> Tom Lane wrote:
>> I think we used to do it more or less like that, but people didn't like
>> it because they couldn't do any long-range planning.
> Does the current system help long-range planning?
> I could imagine an enterprise plan that says "we'll upgrade to
> the curren
Bruce Momjian wrote:
> Kevin Grittner wrote:
>> To what do you attribute the extended time needed to handle the
>> final CF? How can that be made better?
>
> We had many patches that had been through previous commit-fests with
> minor adjustments and we had to finalize them before we could close
This code:
CREATE OR REPLACE FUNCTION foo() returns boolean as $$
DECLARE
have_rec record;
want_rec record;
BEGIN
have_rec := row(1, 2);
want_rec := row(3, 5);
RETURN have_rec IS DISTINCT FROM want_rec;
END;
$$ language plpgsql;
SEL
Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > I realize there is the perception that the large patches that were
> > eventually rejected held up the release, but for all the patches I
> > can think of, they were not rejected immediately _because_ we had
> > other valid patches to work on.
Ron Mayer wrote:
> But in neither case does it help my long term planning to know if
> the current version January release is scheduled to be called 8.4
> or 8.5 or 9.1 (which is really all that the current system helps
> me predict).
The numbering is typically decided near the end of the devel c
Ron Mayer wrote:
> I could imagine an enterprise plan that says "we'll upgrade to
> the current production release in January [after christmas sales]";
> or "we'll begin to upgrade the January after [feature-x] is in
> production".
>
> But in neither case does it help my long term planning to
On Wed, Jul 1, 2009 at 12:09 PM, Josh Berkus wrote:
> The main reason not to have one is that given byte-alignment, 95% of the
> time using a tinyint would save no actual disk space or memory over just
> using INT2 (or indeed INT4). I'll point out that the MySQLers are enamored
> of the 3-byte int
On Wed, Jul 01, 2009 at 11:51:28AM -0400, Robert Haas wrote:
> Tom wrote upthread:
> # If you find yourself with nothing else to do except review a new patch
> # during beta, then sure, go do it. But is there *really* nothing you
> # could be doing to help expedite the beta?
>
> My honest answer
Tom Lane wrote:
"Joshua D. Drake" writes:
We already push and pull our release dates based are what in the queue,
we just do so informally. Why not just make it part of the process?
I think we used to do it more or less like that, but people didn't like
it because they couldn't do any long-ra
Caleb Cushing writes:
> On Wed, Jul 1, 2009 at 11:41 AM, Kevin
> Grittner wrote:
>> Many databases
>> support a TINYINT type as a single-byte value, although I'm not sure
>> there's consistency on whether that's a signed or unsigned value.
> wouldn't any implementation in pg support both?
Introd
On Jul 1, 2009, at 9:27 AM, Tom Lane wrote:
It is? When did that happen?
http://archives.postgresql.org/pgsql-committers/2009-04/msg00111.php
Thanks. Change added to the wiki.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscri
"David E. Wheeler" writes:
> On Jul 1, 2009, at 9:07 AM, Tom Lane wrote:
>> The FAQ is on the wiki now ... fix it yourself.
> It is? When did that happen?
http://archives.postgresql.org/pgsql-committers/2009-04/msg00111.php
regards, tom lane
--
Sent via pgsql-hackers m
On Wed, Jul 1, 2009 at 11:41 AM, Kevin
Grittner wrote:
> I think you mean byte where you've said bit.
you're correct. I'm being a nerf.
> Boolean would be
> adequate for a single bit, and I haven't (so far) seen any database
> which supports both a single-bit type and a boolean.
wasn't aware of
On Wed, 2009-07-01 at 09:15 -0700, David E. Wheeler wrote:
> On Jul 1, 2009, at 9:07 AM, Tom Lane wrote:
>
> >> Just a reminder, Bruce, to add the CITEXT bit to the FAQ when 8.4 is
> >> released. Is that supposed to be today?
> >
> > The FAQ is on the wiki now ... fix it yourself.
>
> It is? When
Josh Berkus writes:
> But ... the nice thing about PostgreSQL is that data types can be loaded
> at runtime. Which means that you don't need INT1 in core for it to be
> useful to you and others; just write the data type and put it on
> pgFoundry.
Yeah. The argument against that used to be th
On Jul 1, 2009, at 9:07 AM, Tom Lane wrote:
Just a reminder, Bruce, to add the CITEXT bit to the FAQ when 8.4 is
released. Is that supposed to be today?
The FAQ is on the wiki now ... fix it yourself.
It is? When did that happen?
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-h
Caleb.
I'd like to see this topic revisited since as far as I can see it
hasn't been seriously discussed in years. I believe the main arguments
against are why do we need more more numeric datatypes and increased
maintenance. It would seem to me that a tinyint datatype maintenance
wise would get
"David E. Wheeler" writes:
> Just a reminder, Bruce, to add the CITEXT bit to the FAQ when 8.4 is
> released. Is that supposed to be today?
The FAQ is on the wiki now ... fix it yourself.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
On Feb 6, 2009, at 10:54 AM, David E. Wheeler wrote:
On Feb 6, 2009, at 9:43 AM, Bruce Momjian wrote:
Oh. That seems kind of odd?can you hang onto the patch until 8.4 is
released, then? This must happen all the time, no?
OK, I will hang on to it, but I will have to mention it is only in
8.
Dear Mr. Masao
My name is Damon.
I read your comments regarding pg_standby warm backup. "New trigger option
of pg_standby".
I got several questions on this article.
1. I don't know why I have to trigger twice when switching from
pg_standby status to normal status?
I saw t
On Wed, Jul 1, 2009 at 10:30 AM, Kevin
Grittner wrote:
> Bruce Momjian wrote:
>> I realize there is the perception that the large patches that were
>> eventually rejected held up the release, but for all the patches I
>> can think of, they were not rejected immediately _because_ we had
>> other va
Caleb Cushing wrote:
> most (if not all?) of posgresql's major competitor's (mysql, sql
> server, db2, etc) support a single bit integer datatype.
> A couple of times I've been told "you don't need tinyint, use
> boolean" which is not true, several projects I've worked on I've
> needed and in
Ugh, I disagree. I agree that we were too generous with letting
people rework patches while the CommitFest was in progress (mostly, we
let people drop off the map for 3 weeks and then come back and say,
oh, here's my revised version). But you have to allow a certain
amount of reworking as the
I'd like to see this topic revisited since as far as I can see it
hasn't been seriously discussed in years. I believe the main arguments
against are why do we need more more numeric datatypes and increased
maintenance. It would seem to me that a tinyint datatype maintenance
wise would get all the s
Tom Lane writes:
> I have zero interest in trying to support either. I doubt it's even
> possible --- the backend code has no way to inform the dynamic loader
> how to resolve cross-library references. So if the DL doesn't already
> understand the dependency it's never going to work.
Ok, that m
Toshihiro Kitagawa wrote:
> - shared_buffers = 128MB
What happens with a larger value for shared_buffers?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
COPY performance issue is discussed in the following threads,
and it seems the conclusion was 8.4rc2 has been improved.
http://archives.postgresql.org/pgsql-hackers/2009-06/msg01133.php
However, I didn't see difference of COPY performance between 8.4rc1
and 8.4rc2.
It seems that a COPY to 8.4rc
Dimitri Fontaine writes:
> Tom Lane writes:
>> You should be able to configure the dynamic loader to do that, although
>> in the case of uuid I strongly doubt it's worth the trouble.
> In the context of the extensions facility, will we be able to do this
> configuration automatically from the ba
Bruce Momjian wrote:
> I realize there is the perception that the large patches that were
> eventually rejected held up the release, but for all the patches I
> can think of, they were not rejected immediately _because_ we had
> other valid patches to work on. Once all valid patches were
> app
Tom Lane writes:
> You should be able to configure the dynamic loader to do that, although
> in the case of uuid I strongly doubt it's worth the trouble.
In the context of the extensions facility, will we be able to do this
configuration automatically from the backend, or to "manually" load any
d
"Fly.Li" writes:
> version: PG8.2.2
> MY Question:
> Why must "take the same number of parameters" ?
Because the GIN code will call it with a particular number of arguments.
> When I use tsearch2, I found that gin_extract_tsquery() has 3 parameters, it
> break the rule "take the same number of
Dimitri Fontaine writes:
> Any advice or missing knowledge about loading modules which depends on
> code from another module not already loaded in the backend is welcome :)
You should be able to configure the dynamic loader to do that, although
in the case of uuid I strongly doubt it's worth the
version: PG8.2.2
MY Question:
Why must "take the same number of parameters" ?
" We can check that all the referenced instances of the same support routine
number take the same number of parameters" ?
1 there is no results by running regress test as follow:
plsql/src/test/regress/sql/opr_sanity.
and...@dunslane.net (Andrew Dunstan) writes:
> Jeff Davis wrote:
>> On Mon, 2009-06-29 at 12:55 -0400, Tom Lane wrote:
>>
>>> I think it has to be looked at in comparison to more general
>>> prospective-permissions schemes;
>>
>> When I searched google for "prospective permissions", all I found we
On Wed, 2009-07-01 at 02:14 -0400, Robert Haas wrote:
> Basically, if we're too quick to bump patches to the next CommitFest,
> there will be only moderate resistance for the first N-1 CommitFests,
> but then for the last CommitFest people won't want to be bumped by a
> whole major release for wh
1 - 100 of 104 matches
Mail list logo
