--On Montag, August 03, 2009 12:38:48 -0400 Robert Haas
robertmh...@gmail.com 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
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
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
On Mon, Aug 03, 2009 at 11:21:43AM -0400, Tom Lane wrote:
Kevin Grittner kevin.gritt...@wicourts.gov 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
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 Tue, Aug 4, 2009 at 12:18 AM, Tom Lanet...@sss.pgh.pa.us 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
Greg Stark gsst...@mit.edu writes:
On Tue, Aug 4, 2009 at 12:18 AM, Tom Lanet...@sss.pgh.pa.us 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
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_position (and
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 that
Tom Lane wrote:
Greg Stark gsst...@mit.edu writes:
On Tue, Aug 4, 2009 at 12:18 AM, Tom Lanet...@sss.pgh.pa.us 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
Alvaro Herrera alvhe...@commandprompt.com 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
2009/8/3 KaiGai Kohei kai...@ak.jp.nec.com:
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
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
Alvaro Herrera alvhe...@commandprompt.com 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
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
On Thu, Jul 30, 2009 at 1:22 AM, Pavel Stehulepavel.steh...@gmail.com wrote:
2009/7/30 Robert Haas robertmh...@gmail.com:
On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehulepavel.steh...@gmail.com
wrote:
Hello
new patch add new contrib transformations with three modules
anotation, decode and
-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.
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
2009/8/3 Brendan Jurd dire...@gmail.com:
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
Robert Haas wrote:
2009/8/3 KaiGai Kohei kai...@ak.jp.nec.com:
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
2009/8/3 Tom Lane t...@sss.pgh.pa.us:
Euler Taveira de Oliveira eu...@timbira.com 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
Joe Conway m...@joeconway.com 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
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 CommitFest
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 archives
-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 given our
Joe Conway m...@joeconway.com 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
On Mon, Aug 3, 2009 at 10:03 PM, Tom Lanet...@sss.pgh.pa.us 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
-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 do
Brendan Jurd dire...@gmail.com 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
Robert Haas robertmh...@gmail.com writes:
On Mon, Aug 3, 2009 at 10:03 PM, Tom Lanet...@sss.pgh.pa.us 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
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 SE-PostgreSQL
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.
2009/8/4 Tom Lane t...@sss.pgh.pa.us:
Brendan Jurd dire...@gmail.com 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
Brendan Jurd dire...@gmail.com writes:
2009/8/4 Tom Lane t...@sss.pgh.pa.us:
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
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
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 3, 2009 at 10:19 PM, Stephen Frostsfr...@snowman.net 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
On Mon, Aug 3, 2009 at 10:44 PM, Andrew Dunstanand...@dunslane.net 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
On Mon, Aug 3, 2009 at 10:40 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Aug 3, 2009 at 10:03 PM, Tom Lanet...@sss.pgh.pa.us wrote:
I think that the least painful solution might be to change
pg_proc.probin to be declared as text. Otherwise we're
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 these
2009/8/4 Tom Lane t...@sss.pgh.pa.us:
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,
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 a huge
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_Abstraction
I'm not
-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 do
2009/8/4 Robert Haas robertmh...@gmail.com:
On Thu, Jul 30, 2009 at 1:22 AM, Pavel Stehulepavel.steh...@gmail.com wrote:
2009/7/30 Robert Haas robertmh...@gmail.com:
On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehulepavel.steh...@gmail.com
wrote:
Hello
new patch add new contrib transformations
Tom Lane t...@sss.pgh.pa.us writes:
Tao Ma feng_e...@163.com 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,
2009/8/4 Tom Lane t...@sss.pgh.pa.us:
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
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
Pavel Stehule pavel.steh...@gmail.com writes:
2009/8/4 Tom Lane t...@sss.pgh.pa.us:
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
2009/8/4 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2009/8/4 Tom Lane t...@sss.pgh.pa.us:
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
2009/8/4 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2009/8/4 Tom Lane t...@sss.pgh.pa.us:
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
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?
It might not be as perfect a solution as teaching the planner to know
about unique indexes, but it is better than
--On Sonntag, August 02, 2009 11:38:22 -0400 Robert Haas
robertmh...@gmail.com wrote:
What's the current status of this patch? Is someone (either Pavel or
Bernd) planning to update it further, or should it be marked Ready for
Committer?
I will incorporate some additional docs adjustments
Stephen Frost wrote:
I think what I should do on the next is ...
- To check up whether it is really possible to implement SELinux's model.
- To describe the list of the security functions in the new abstraction
layer.
- To discuss the list of permission at:
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.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
--
Sent
2009/8/3 Bernd Helmle maili...@oopsware.de:
--On Sonntag, August 02, 2009 11:38:22 -0400 Robert Haas
robertmh...@gmail.com wrote:
What's the current status of this patch? Is someone (either Pavel or
Bernd) planning to update it further, or should it be marked Ready for
Committer?
I will
On Sat, Aug 1, 2009 at 20:30, Kevin Fieldkevinjamesfi...@gmail.com wrote:
The event viewer says:
The description for Event ID ( 0 ) in Source ( PostgreSQL ) cannot
be
found. The local computer may not have the necessary registry
information or message DLL files to display messages from
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 careful, look.
The sheer scope
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
* 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 should
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
On Aug 3, 2009, at 7:57 AM, Stephen Frost sfr...@snowman.net 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
Kim Bisgaard kim...@alleroedderne.adsl.dk 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
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.
Andrew Dunstan and...@dunslane.net 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.
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
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
2009/8/3 Steve Prentice prent...@cisco.com:
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 -
Tatsuo Ishii is...@postgresql.org 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
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
I wrote:
Tom Lane t...@sss.pgh.pa.us 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.
Andrew Dunstan and...@dunslane.net 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
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
On Monday 03 August 2009 17:44:32 Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
On Mon, Aug 03, 2009 at 10:44:32AM -0400, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
Kevin Grittner kevin.gritt...@wicourts.gov 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
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.
--
Tatsuo Ishii
SRA
David Fetter da...@fetter.org 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
Peter Eisentraut pete...@gmx.net 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
On Mon, Aug 3, 2009 at 11:22 AM, Tatsuo Ishiiis...@postgresql.org 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
On Mon, Aug 03, 2009 at 11:32:48AM -0400, Tom Lane wrote:
David Fetter da...@fetter.org 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
David Fetter da...@fetter.org 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,
On Mon, Aug 3, 2009 at 17:32, Tom Lanet...@sss.pgh.pa.us wrote:
David Fetter da...@fetter.org 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
Boszormenyi Zoltan z...@cybertec.at 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
On Mon, Aug 3, 2009 at 10:51 AM, Pavel Stehulepavel.steh...@gmail.com wrote:
2009/8/3 Steve Prentice prent...@cisco.com:
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
Magnus Hagander mag...@hagander.net 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
Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at 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
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 three
On Mon, Aug 03, 2009 at 12:19:40PM -0400, Tom Lane wrote:
David Fetter da...@fetter.org 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
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
Bernd Helmle maili...@oopsware.de writes:
--On Samstag, Juli 11, 2009 13:40:44 +0300 Peter Eisentraut
pete...@gmx.net 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
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
--On Montag, August 03, 2009 12:38:48 -0400 Robert Haas
robertmh...@gmail.com 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
--On Montag, August 03, 2009 15:11:08 -0400 Tom Lane t...@sss.pgh.pa.us
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
--On Montag, August 03, 2009 12:18:13 -0700 Steve Prentice
prent...@cisco.com 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
Bernd Helmle maili...@oopsware.de 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-Firstdiff=6391oldid=6250
-Kevin
--
Sent via pgsql-hackers mailing list
On Mon, Aug 3, 2009 at 2:07 PM, David Fetterda...@fetter.org wrote:
On Mon, Aug 03, 2009 at 12:19:40PM -0400, Tom Lane wrote:
David Fetter da...@fetter.org 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
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.
Bernd Helmle maili...@oopsware.de writes:
--On Montag, August 03, 2009 15:11:08 -0400 Tom Lane t...@sss.pgh.pa.us
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
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
1 - 100 of 107 matches
Mail list logo
