2009/8/4 Tom Lane :
> Pavel Stehule writes:
>> 2009/8/4 Tom Lane :
>>> I think that the least painful solution might be to change
>>> pg_proc.probin to be declared as text.
>
>> correct solution is moving the path to prosrc col or create new colum
>> "externalproc". I thing so probin should be use
2009/8/4 Tom Lane :
> Pavel Stehule writes:
>> 2009/8/4 Tom Lane :
>>> I think that the least painful solution might be to change
>>> pg_proc.probin to be declared as text.
>
>> correct solution is moving the path to prosrc col or create new colum
>> "externalproc". I thing so probin should be use
Pavel Stehule writes:
> 2009/8/4 Tom Lane :
>> I think that the least painful solution might be to change
>> pg_proc.probin to be declared as text.
> correct solution is moving the path to prosrc col or create new colum
> "externalproc". I thing so probin should be useful for plpgsql -
> sometime
Joe Conway escribió:
> OK, how's this look?
Hmm, is it possible to use OUT parameters in the function instead of
declaring a new type for the result?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 supp
2009/8/4 Tom Lane :
> pg_proc.probin is currently declared as being type bytea. Perhaps that
> had some real utility once upon a time, but no currently defined
> procedural language stores binary data there. In fact, the only
> thing that gets stored there is the shared-library file name for
> C
"Tom Lane" writes:
> "Tao Ma" writes:
>> I knew that the delete_function() will reclaim the memory context
>> allocated for the function. But I did not find any code for removing
>> the plan(SPI plan memory context), saved by calling _SPI_save_plan.
>
> Hmmm ... good point, those probably won't g
2009/8/4 Robert Haas :
> On Thu, Jul 30, 2009 at 1:22 AM, Pavel Stehule wrote:
>> 2009/7/30 Robert Haas :
>>> On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehule
>>> wrote:
Hello
new patch add new contrib "transformations" with three modules
anotation, decode and json.
The
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Tom Lane wrote:
> [ thinks for awhile... ] Actually, it seems to me that the present
> patch's definition of the function would be very hard to work with.
> You would normally want to work with the events one at a time.
> There isn't much you could
David Fetter wrote:
> On Mon, Aug 03, 2009 at 11:18:55PM -0400, Stephen Frost wrote:
>> KaiGai,
>>
>> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>>> I began to describe the list of abstraction layer functions (but not
>>> completed yet):
>>> http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstrac
On Mon, Aug 03, 2009 at 11:18:55PM -0400, Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> > I began to describe the list of abstraction layer functions (but not
> > completed yet):
> > http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstraction
>
> I'm not really
2009/8/4 Tom Lane :
> BTW, there's no rule saying you have to fix that strictly within
> to_char(). It might make more sense to have numeric.c export a
> function that is like numeric_out but produces e-style output.
> Your choice as the patch writer, but keep it in mind ...
>
Ah, thanks for the
Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> I began to describe the list of abstraction layer functions (but not
>> completed yet):
>> http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstraction
>
> I'm not really a huge fan of 'security_' as a prefix for th
On Mon, Aug 3, 2009 at 10:40 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Aug 3, 2009 at 10:03 PM, Tom Lane wrote:
>>> I think that the least painful solution might be to change
>>> pg_proc.probin to be declared as text. Otherwise we're going to need
>>> version-specific klugery in pg_dum
On Mon, Aug 3, 2009 at 10:44 PM, Andrew Dunstan wrote:
> Tom Lane wrote:
>>>
>>> 3) I couldn't see any way to assign myself as the committer.
>>>
>>
>> Yeah, the webapp doesn't explicitly record the committer for a patch.
>> What I've been doing is adding a comment saying that I'm taking a patch
>>
On Mon, Aug 3, 2009 at 10:19 PM, Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> So, we may be able to modify the development plan as follows:
>> * 2nd CommitFest (15-Sep)
>> - security abstraction layer
>> (- largeobject permission)
>>
>> * 3rd CommitFest (15-No
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> I began to describe the list of abstraction layer functions (but not
> completed yet):
> http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstraction
I'm not really a huge fan of 'security_' as a prefix for these
functions, but I don't have a
On Mon, Aug 03, 2009 at 10:03:11PM -0400, Tom Lane wrote:
> However, with the hex bytea output patch in place, it's *completely*
> broken. I offer the following pg_dump output:
>
> CREATE FUNCTION interpt_pp(path, path) RETURNS point
> LANGUAGE c
> AS
> '\\x2f686f6d652f706f7374677265732f
Brendan Jurd writes:
> 2009/8/4 Tom Lane :
>> What I'd consider instead is calling numeric_out and then working
>> with the result of that. It would always be f-format, so you'd
>> have to do your own conversion to e-format, but you could do it
>> without any risk of precision or range loss.
> Y
2009/8/4 Tom Lane :
> Brendan Jurd writes:
>> Well, I tried this and as it turns out the patch casts the value to a
>> float8 in order to pass it on to snprintf for sci-notation formatting.
>
> Well, that's pretty dumb. Quite aside from the range problem, that
> would mean that you lose everythin
Tom Lane wrote:
3) I couldn't see any way to assign myself as the committer.
Yeah, the webapp doesn't explicitly record the committer for a patch.
What I've been doing is adding a comment saying that I'm taking a patch
to commit. A separate field would probably be better though.
Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> So, we may be able to modify the development plan as follows:
>> * 2nd CommitFest (15-Sep)
>> - security abstraction layer
>> (- largeobject permission)
>>
>> * 3rd CommitFest (15-Nov)
>> - basic functionality of
Robert Haas writes:
> On Mon, Aug 3, 2009 at 10:03 PM, Tom Lane wrote:
>> I think that the least painful solution might be to change
>> pg_proc.probin to be declared as text. Otherwise we're going to need
>> version-specific klugery in pg_dump and who knows where else.
> Will that require a spec
Brendan Jurd writes:
> Well, I tried this and as it turns out the patch casts the value to a
> float8 in order to pass it on to snprintf for sci-notation formatting.
Well, that's pretty dumb. Quite aside from the range problem, that
would mean that you lose everything past the sixteenth or so di
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Tom Lane wrote:
> [ thinks for awhile... ] Actually, it seems to me that the present
> patch's definition of the function would be very hard to work with.
> You would normally want to work with the events one at a time.
> There isn't much you could
On Mon, Aug 3, 2009 at 10:03 PM, Tom Lane wrote:
> pg_proc.probin is currently declared as being type bytea. Perhaps that
> had some real utility once upon a time, but no currently defined
> procedural language stores binary data there. In fact, the only
> thing that gets stored there is the shar
Joe Conway writes:
> In reference to:
> http://archives.postgresql.org/message-id/6534f7ae0811181547v1dc1f096g6222e8273b461...@mail.gmail.com
> Had to fix a lot of bit rot, but otherwise looks good. My updated patch
> attached. Will commit in a day or so if no objections.
After a quick look-over
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Alvaro Herrera wrote:
> Joe Conway escribió:
>
>> 2) It would be nice if the mail archive web page of the original message
>> had a "Reply To" button. Otherwise I guess I can do what I've done above.
>
> I totally agree, but this is not workable gi
Joe Conway escribió:
> 2) It would be nice if the mail archive web page of the original message
> had a "Reply To" button. Otherwise I guess I can do what I've done above.
I totally agree, but this is not workable given our current software.
I've been giving some time to reworking the email archi
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> So, we may be able to modify the development plan as follows:
> * 2nd CommitFest (15-Sep)
> - security abstraction layer
> (- largeobject permission)
>
> * 3rd CommitFest (15-Nov)
> - basic functionality of SE-PostgreSQL
>
> * 4th CommitFe
Joe Conway writes:
> BTW, some commitfest procedural comments/questions:
> 1) I couldn't figure out how to attach my patch to the commitfest page
> short of cut-n-paste into the small comment text box -- is that my only
> choice?
No, what you should do is first send the patch to -hackers, then p
2009/8/3 Tom Lane :
> Euler Taveira de Oliveira writes:
>> As I said in a prior e-mail, Oracle has a diferent overflow limit (-84 to
>> 127).
>> In PostgreSQL, the numeric datatype can have up to 1000 digits (ie 1e+999)
>> and
>> the double precision datatype can have up to 309 digits (ie 1e-307
Robert Haas wrote:
> 2009/8/3 KaiGai Kohei :
>> I now plans to submit two patches for the next commit fest.
>> The one is implementation of the abstraction layer.
>> The other is basic implementation of the SE-PostgreSQL.
>
> Is this a good idea, or would it be better to focus on the aclcheck
> st
2009/8/3 Brendan Jurd :
> Okay, so Oracle just forces the output wider to accomodate the
> exponent (i.e., you can't rely on it being fixed-width).
>
> I can adjust the patch to imitate this behaviour; should be able to
> post a new revision within 24 hours.
>
Please find attached version 5 of the
pg_proc.probin is currently declared as being type bytea. Perhaps that
had some real utility once upon a time, but no currently defined
procedural language stores binary data there. In fact, the only
thing that gets stored there is the shared-library file name for
C functions. To make things eve
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
In reference to:
http://archives.postgresql.org/message-id/6534f7ae0811181547v1dc1f096g6222e8273b461...@mail.gmail.com
Had to fix a lot of bit rot, but otherwise looks good. My updated patch
attached. Will commit in a day or so if no objections.
BT
On Thu, Jul 30, 2009 at 1:22 AM, Pavel Stehule wrote:
> 2009/7/30 Robert Haas :
>> On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehule
>> wrote:
>>> Hello
>>>
>>> new patch add new contrib "transformations" with three modules
>>> anotation, decode and json.
>>>
>>> These modules are ported from my olde
> Fortunately, there's already a specification discussed for this. We'd
> like to have the ability for each column to have both a logical position
> and a physical position which are separate. This would also allow us to
> dynamically re-arrange the columns at CREATE time for best storage
>
Alvaro Herrera writes:
> Tom Lane wrote:
>> Well, unless you want to leave *all* the bytea functions in builtins.h
>> there will still be some risk there. I'd actually sooner break calls
>> of byteaout than other things, because in reality every caller of
>> byteaout is going to need to be inspec
Tom Lane wrote:
> Alvaro Herrera writes:
> > I vote for a new bytea.h file that does not slurp in byteain/byteaout,
> > to avoid breaking 3rd party code. miscadmin.h seems the worst solution,
> > since it's already included in 210 other files.
>
> Well, unless you want to leave *all* the bytea f
2009/8/3 KaiGai Kohei :
> I now plans to submit two patches for the next commit fest.
> The one is implementation of the abstraction layer.
> The other is basic implementation of the SE-PostgreSQL.
Is this a good idea, or would it be better to focus on the aclcheck
stuff (which is what I understan
Alvaro Herrera writes:
> I vote for a new bytea.h file that does not slurp in byteain/byteaout,
> to avoid breaking 3rd party code. miscadmin.h seems the worst solution,
> since it's already included in 210 other files.
Well, unless you want to leave *all* the bytea functions in builtins.h
there
Tom Lane wrote:
> Greg Stark writes:
> > On Tue, Aug 4, 2009 at 12:18 AM, Tom Lane wrote:
> >> One other stylistic gripe: I don't much like inserting a GUC variable
> >> definition into builtins.h --- that file has traditionally only
> >> contained function extern declarations. �The best alternati
Jwexler,
Please suggest how best to propose that the following feature be added to
PostgreSQL's roadmap?
Ability to "Alter column position" as described in the section "Adding alter column
syntax into postgres" of http://wiki.postgresql.org/wiki/Alter_column_position (and the two
links in th
JwexlerAt MailDotCom wrote:
> Please suggest how best to propose that the following feature be added to
> PostgreSQL's roadmap?
>
> Ability to "Alter column position" as described in the section "Adding alter
> column syntax into postgres" of
> http://wiki.postgresql.org/wiki/Alter_column_posit
Greg Stark writes:
> On Tue, Aug 4, 2009 at 12:18 AM, Tom Lane wrote:
>> One other stylistic gripe: I don't much like inserting a GUC variable
>> definition into builtins.h --- that file has traditionally only
>> contained function extern declarations. The best alternative I can
>> think of is to
On Tue, Aug 4, 2009 at 12:18 AM, Tom Lane wrote:
> One other stylistic gripe: I don't much like inserting a GUC variable
> definition into builtins.h --- that file has traditionally only
> contained function extern declarations. The best alternative I can
> think of is to move the bytea-related st
Please suggest how best to propose that the following feature be added to
PostgreSQL's roadmap?
Ability to "Alter column position" as described in the section "Adding alter
column syntax into postgres" of
http://wiki.postgresql.org/wiki/Alter_column_position (and the two links in
that section)
On Mon, Aug 03, 2009 at 11:21:43AM -0400, Tom Lane wrote:
> "Kevin Grittner" writes:
> > Over the weekend I ran 40 restores of Milwaukee County's production
> > data using Friday's snapshot with and without the patch. I alternated
> > between patched and unpatched. It appears that this latest ve
Greg Williamson wrote:
> KaiGai --
>
> I was pulled away from any work on this for a few days ... what can I do
> to help, if anything ? (Keeping in mind that my knowledge of the internals
> of postgres is, alas, minimal.) ... I had a quick look at this new page and
> want to take another, more ca
One other stylistic gripe: I don't much like inserting a GUC variable
definition into builtins.h --- that file has traditionally only
contained function extern declarations. The best alternative I can
think of is to move the bytea-related stuff into a new include file
include/utils/bytea.h. Has a
--On Montag, August 03, 2009 12:38:48 -0400 Robert Haas
wrote:
Let's get back to focusing on the patch that is actually under
consideration here.
Status Report: I will finish documentation and review tomorrow and will
mark this patch for committer review.
--
Thanks
Be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Joe Conway wrote:
> If there are no objections, I'll commit in a day or two.
Attached version committed. Only difference from the last is catversion.
Joe
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedo
Are you volunteering?
Maybe; is there a template where I can access it?
Robert pointed out I ought to get involved anyway for 8.5 so that we can
stop having separate "release notes" and "public" versions of the new
features.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sen
Josh Berkus wrote:
Are we going to ship ChangeLog files or some such, giving that we're not
going to have release notes?
I still think we should be doing release notes for the Alphas. It
will limit the pain of doing release notes for the final release;
they'll be done already except form
Josh Berkus writes:
>> Are we going to ship ChangeLog files or some such, giving that we're not
>> going to have release notes?
> I still think we should be doing release notes for the Alphas.
Are you volunteering?
regards, tom lane
--
Sent via pgsql-hackers mailing li
Are we going to ship ChangeLog files or some such, giving that we're not
going to have release notes?
I still think we should be doing release notes for the Alphas. It will
limit the pain of doing release notes for the final release; they'll be
done already except formatting.
--
Josh Berk
Josh Berkus wrote:
> I think we need some kind of docs up, otherwise we'll get little
> actual testing. As previously discussed, building the docs yourself
> from pure source involves several complicated dependancies which
> aren't available on all platforms.
Are we going to ship ChangeLog files
IIRC daveg was volunteering to do some tests with his own data; maybe
we should wait for those results.
Unfortunately, I've lost access to the client's data which was showing
bad behaviour under the first heuristic.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql
Peter,
There's another question for alpha releases: are we going to build docs?
Either for www.postgresql.org, or for PGDATA/docs?
I think we need some kind of docs up, otherwise we'll get little actual
testing. As previously discussed, building the docs yourself from pure
source involves
Bernd Helmle writes:
> --On Montag, August 03, 2009 15:11:08 -0400 Tom Lane
> wrote:
>> I'm starting to look at this patch. I observe that it's setting the
>> default output format to HEX. If changing the default behavior was
>> agreed to, or even discussed, I do not remember where. Shouldn't
On Mon, Aug 03, 2009 at 09:22:52PM +0300, Peter Eisentraut wrote:
> On Monday 03 August 2009 21:07:00 David Fetter wrote:
> > We require that people supply docs with their changes, and it is
> > totally unreasonable to let them send in catalog changes which do
> > not include need migration changes
On Mon, Aug 3, 2009 at 2:07 PM, David Fetter wrote:
> On Mon, Aug 03, 2009 at 12:19:40PM -0400, Tom Lane wrote:
>> David Fetter writes:
>> > On Mon, Aug 03, 2009 at 11:32:48AM -0400, Tom Lane wrote:
>> >> And I doubt we'd bother generating pg_migrator builds that work
>> >> for pairs of alpha rele
Bernd Helmle wrote:
> Please note that Steve's suggestion is linked into the commitfest
> since 2009-05-21, too.
Yeah:
http://wiki.postgresql.org/index.php?title=CommitFest_2009-First&diff=6391&oldid=6250
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
--On Montag, August 03, 2009 12:18:13 -0700 Steve Prentice
wrote:
I added it as a comment because it wouldn't make since to commit it or
even review it separately.
That was exactly i was understanding it.
--
Thanks
Bernd
--
Sent via pgsql-hackers mailing list (pgsql-ha
--On Montag, August 03, 2009 15:11:08 -0400 Tom Lane
wrote:
I'm starting to look at this patch. I observe that it's setting the
default output format to HEX. If changing the default behavior was
agreed to, or even discussed, I do not remember where. Shouldn't the
default stay the same?
I
--On Montag, August 03, 2009 12:38:48 -0400 Robert Haas
wrote:
I'm a little confused here. We are 19 days into a 31 day CommitFest;
you are almost three weeks too late to add a patch to the queue.
Unless you can convince a friendly committer to pick this up out of
sequence, I think the only p
On Aug 3, 2009, at 9:38 AM, Robert Haas wrote:
I sent several notes adding for all patches to be added to
commitfest.postgresql.org prior to the start of CommitFest; AFAIK,
this one was never added.
Hi Robert,
The patch for plpgsql was added as a comment to Pavel's patch. I added
it as a com
Bernd Helmle writes:
> --On Samstag, Juli 11, 2009 13:40:44 +0300 Peter Eisentraut
> wrote:
>> OK, here is an updated patch. It has the setting as enum, completed
>> documentation, and libpq support. I'll add it to the commit fest in the
>> hope that someone else can look it over in detail.
On Monday 03 August 2009 21:07:00 David Fetter wrote:
> We require that people supply docs with their changes, and it is
> totally unreasonable to let them send in catalog changes which do not
> include need migration changes. That's how it works in every other
> RDBMS outfit that has changes on d
On Mon, Aug 03, 2009 at 12:19:40PM -0400, Tom Lane wrote:
> David Fetter writes:
> > On Mon, Aug 03, 2009 at 11:32:48AM -0400, Tom Lane wrote:
> >> And I doubt we'd bother generating pg_migrator builds that work
> >> for pairs of alpha releases.
>
> > That's an interesting idea. Shouldn't pg_mig
>> ok - I don't though about it. My goal is integration main parser next
>> commitfest, but it is true, so somebody would to play with named
>> params now. Commiting of Steve's patch doesn't break anything.
>
> I'm a little confused here. We are 19 days into a 31 day CommitFest;
> you are almost t
Tom Lane írta:
> Boszormenyi Zoltan writes:
>
>> new versions attached, updated to apply to the current CVS cleanly.
>>
>
> Why is this messing with the core grammar?
>
> regards, tom lane
>
It was explained in earlier mails, let me explain it again
but a bit more
Magnus Hagander writes:
> I haven't actually looked into pg_migrator enough to know how likely
> it is that it'll "just work" going alpha->alpha when there have only
> been "normal" changes? How invasive are the changes that actually
> require pg_migrator to be touched at all?
To my mind there ar
On Mon, Aug 3, 2009 at 10:51 AM, Pavel Stehule wrote:
> 2009/8/3 Steve Prentice :
>> On Aug 3, 2009, at 1:41 AM, Pavel Stehule wrote:
>>
>>> I should to wait with Steve patch - I would to add main sql parser
>>> into plpgsql - than Steve's patch is unnecessary. But if there will be
>>> some problem
Boszormenyi Zoltan writes:
> new versions attached, updated to apply to the current CVS cleanly.
Why is this messing with the core grammar?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On Mon, Aug 3, 2009 at 17:32, Tom Lane wrote:
> David Fetter writes:
>> On Mon, Aug 03, 2009 at 10:44:32AM -0400, Tom Lane wrote:
>>> and it doesn't scale to consider the possibility that we might want
>>> to re-release an alpha after fixing some particularly evil bug. A
>>> tag without a branch
David Fetter writes:
> On Mon, Aug 03, 2009 at 11:32:48AM -0400, Tom Lane wrote:
>> And I doubt we'd bother generating pg_migrator builds that work for
>> pairs of alpha releases.
> That's an interesting idea. Shouldn't pg_migrator be mandated to work
> for *any* catversion bump?
Oh, are you vo
On Mon, Aug 03, 2009 at 11:32:48AM -0400, Tom Lane wrote:
> David Fetter writes:
> > On Mon, Aug 03, 2009 at 10:44:32AM -0400, Tom Lane wrote:
> >> and it doesn't scale to consider the possibility that we might want
> >> to re-release an alpha after fixing some particularly evil bug. A
> >> tag w
On Mon, Aug 3, 2009 at 11:22 AM, Tatsuo Ishii wrote:
>> > > Personally I was thinking of multi-threaded pgbench as being
>> > > Tatsuo-san's to commit, since that's his code originally.
>> >
>> > Ah see well that's why I post these summaries... :-)
>>
>> Thanks. I consider it a great honor to be al
Peter Eisentraut writes:
> On Monday 03 August 2009 17:44:32 Tom Lane wrote:
>> I feel that making a branch is the way to go. If we try to get away
>> with a shortcut, we'll probably regret it.
> Another more lightweight alternative is to tag and then change the version
> number and build the t
David Fetter writes:
> On Mon, Aug 03, 2009 at 10:44:32AM -0400, Tom Lane wrote:
>> and it doesn't scale to consider the possibility that we might want
>> to re-release an alpha after fixing some particularly evil bug. A
>> tag without a branch won't handle that either.
> Is this a use case? I
> > > Personally I was thinking of multi-threaded pgbench as being
> > > Tatsuo-san's to commit, since that's his code originally.
> >
> > Ah see well that's why I post these summaries... :-)
>
> Thanks. I consider it a great honor to be allowed to commit the
> pacthes.
Patch committed.
--
Tatsu
"Kevin Grittner" writes:
> Over the weekend I ran 40 restores of Milwaukee County's production
> data using Friday's snapshot with and without the patch. I alternated
> between patched and unpatched. It appears that this latest version is
> slightly slower for our production database on the same
On Mon, Aug 03, 2009 at 10:44:32AM -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > Does it need a version number change? Maybe just a tag (no branch)
> > is all that is required.
>
> I think that we do want the alpha releases to identify themselves as
> such. And we want a marker in CVS as t
On Monday 03 August 2009 17:44:32 Tom Lane wrote:
> Andrew Dunstan writes:
> > Does it need a version number change? Maybe just a tag (no branch) is
> > all that is required.
>
> I think that we do want the alpha releases to identify themselves as
> such. And we want a marker in CVS as to what st
That's about 0.52% slower with the patch. Because there was over 10%
variation in the numbers with the patch, I tried leaving out the four
highest outliers on both, in case it was the result of some other
activity on the system (even though this machine should have been
pretty quiet over the we
Andrew Dunstan writes:
> Tom Lane wrote:
>> ... it doesn't scale to consider the possibility that we might
>> want to re-release an alpha after fixing some particularly evil bug.
> Yes, if that's what we want then definitely branch. I guess the branch
> will (almost) only ever have exactly one c
I wrote:
> Tom Lane wrote:
>> Attached is a further small improvement that gets rid of the
>> find_ready_items() scans. After re-reading the patch I realized
>> that it wasn't *really* avoiding O(N^2) behavior ... but this
>> version does.
>
> I'll run a fresh set of benchmarks.
Over the
Tom Lane wrote:
Andrew Dunstan writes:
Does it need a version number change? Maybe just a tag (no branch) is
all that is required.
I think that we do want the alpha releases to identify themselves as
such. And we want a marker in CVS as to what state the alpha release
corresponds t
Tatsuo Ishii writes:
> I got following with CVS Head parser. I'm using bison 2.1 and flex
> 2.5.35. Am I missing something?
Hmm, are you sure that scan.c got remade? I didn't check in detail, but
the errors look a bit like what would happen if the older scanner code
got recompiled against curren
2009/8/3 Steve Prentice :
> On Aug 3, 2009, at 1:41 AM, Pavel Stehule wrote:
>
>> I should to wait with Steve patch - I would to add main sql parser
>> into plpgsql - than Steve's patch is unnecessary. But if there will be
>> some problems, then we can use Steve's patch. It is simple - so there
>>
On Aug 3, 2009, at 1:41 AM, Pavel Stehule wrote:
I should to wait with Steve patch - I would to add main sql parser
into plpgsql - than Steve's patch is unnecessary. But if there will be
some problems, then we can use Steve's patch. It is simple - so there
are not big problems with commit.
I w
Sorry for noise. I regenerated scan.c and gram.c and now everything
works fine.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> I got following with CVS Head parser. I'm using bison 2.1 and flex
> 2.5.35. Am I missing something?
>
> make[3]: Entering directory
> `/usr/local/src/pgsql/current/pgsql/src/bac
Andrew Dunstan writes:
> Does it need a version number change? Maybe just a tag (no branch) is
> all that is required.
I think that we do want the alpha releases to identify themselves as
such. And we want a marker in CVS as to what state the alpha release
corresponds to. Peter's label-and-und
I got following with CVS Head parser. I'm using bison 2.1 and flex
2.5.35. Am I missing something?
make[3]: Entering directory
`/usr/local/src/pgsql/current/pgsql/src/backend/parser'
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels
-fno-strict-aliasing -I. -I../../../src/include
Kim Bisgaard writes:
> Are there plans to make a small follow-up patch to make
> CREATE UNIQUE INDEX on one column
> (and variants in CREATE TABLE ... PRIMARY KEY) automatically do
> SET STATISTICS DISTINCT?
No. It would be pointless for a single column and wrong for
multiple columns.
On Aug 3, 2009, at 7:57 AM, Stephen Frost wrote:
* Peter Eisentraut (pete...@gmx.net) wrote:
- branch
- apply version number change to source tree
- commit
- tag
If this wasn't CVS, this would certainly be the way to go.
or alternatively no tag at all, just apply version number and build
Peter Eisentraut wrote:
As we are approaching the first alpha release, let's think about how to tag
and label it and how to schedule those two operations with respect to one
another.
The typical process for, say, a beta release is
- apply version number change to source tree
- commit
- tag
* Peter Eisentraut (pete...@gmx.net) wrote:
> - branch
> - apply version number change to source tree
> - commit
> - tag
If this wasn't CVS, this would certainly be the way to go.
> or alternatively no tag at all, just apply version number and build tarball.
As this *is* CVS, I'm thinking we sho
As we are approaching the first alpha release, let's think about how to tag
and label it and how to schedule those two operations with respect to one
another.
The typical process for, say, a beta release is
- apply version number change to source tree
- commit
- tag
(repeat for next beta)
The
1 - 100 of 107 matches
Mail list logo
