On Thu, Feb 28, 2013 at 4:56 PM, anara...@anarazel.de and...@anarazel.dewrote:
Hi,
Michael Paquier michael.paqu...@gmail.com schrieb:
Andres, Masao, do you need an extra round or review or do you think
this is
ready to be marked as committer?
On my side I have nothing more to add to the
Hi all
It looks like the commitfest is making very slow progress. At this point
it strikes me that it may be time to look for a line to draw between 9.3
and post-9.3 work, defer all post-9.3 work, and then get the rest into
shape.
As I stepped up to work on the CF and then became immediately
2013-02-27 20:38 keltezéssel, Boszormenyi Zoltan írta:
2013-02-27 20:06 keltezéssel, Stephen Frost írta:
Zoltan,
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
If we get rid of the per-statement variant, there is no need for that either.
For my 2c, I didn't see Tom's comments as saying that
patch, but int2 can also be directly readable and it should
be needed.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
format-width-20130228.patch.bz2
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Umm. sorry,
If you have no problem with this, I'll send this to committer.
I just found that this patch already has a revewer. I've seen
only Status field in patch list..
Should I leave this to you, Dean?
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers
Hello
I have no objections,
Thank you for update
Regards
Pavel
2013/2/28 Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp:
Hello, Could you let me review this patch?
* merged Dean's doc
* allow NULL as width
I understand that this patch aims pure expansion of format's
current
On Thu, Feb 28, 2013 at 2:29 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 26.02.2013 19:42, Tom Lane wrote:
Fujii Masaomasao.fu...@gmail.com writes:
In HEAD, when I ran pg_basebackup -D hoge -X stream,
I got the following FailedAssertion error:
TRAP:
On Thu, Feb 28, 2013 at 3:21 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
Andres, Masao, do you need an extra round or review or do you think this is
ready to be marked as committer?
On my side I have nothing more to add to the existing patches.
Sorry for the late reply.
I found one
On Sat, Feb 23, 2013 at 8:00 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
it is. http://www.postgresql.org/docs/9.2/static/sql-reset.html
DISCARD would be better.
Well, personally, I'm in favor of either TRUNCATE or ALTER
MATERIALIZED VIEW ... DISCARD. I think it's a dangerous
On 28 February 2013 11:25, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote:
Umm. sorry,
If you have no problem with this, I'll send this to committer.
I just found that this patch already has a revewer. I've seen
only Status field in patch list..
Should I leave this to you, Dean?
Robert Haas robertmh...@gmail.com writes:
On Sat, Feb 23, 2013 at 8:00 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
it is. http://www.postgresql.org/docs/9.2/static/sql-reset.html
DISCARD would be better.
Well, personally, I'm in favor of either TRUNCATE or ALTER
MATERIALIZED VIEW
On 28.02.2013 16:55, Robert Haas wrote:
On Sat, Feb 23, 2013 at 8:00 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
it is. http://www.postgresql.org/docs/9.2/static/sql-reset.html
DISCARD would be better.
Well, personally, I'm in favor of either TRUNCATE or ALTER
MATERIALIZED VIEW ...
Changed subject from Strange Windows problem, lock_timeout test request
On Thu, Jan 24, 2013 at 11:41 AM, Andrew Dunstan and...@dunslane.netwrote:
On 01/24/2013 01:44 PM, Jeff Janes wrote:
On Sat, Jan 19, 2013 at 12:15 PM, Andrew Dunstan and...@dunslane.net
wrote:
On 01/19/2013 02:36 AM,
On Thu, Feb 28, 2013 at 11:00 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, personally, I'm in favor of either TRUNCATE or ALTER
MATERIALIZED VIEW ... DISCARD. I think it's a dangerous precedent to
suppose that we're going to start using DISCARD for things that have
nothing to do with the
Robert Haas escribió:
On Thu, Feb 21, 2013 at 12:52 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
One funny thing I noticed is that if I add a column in a table being
dropped, the targetObjects list does not change after the trigger has
run. The reason for this is that the table's
Heikki Linnakangas hlinnakan...@vmware.com wrote:
On 28.02.2013 16:55, Robert Haas wrote:
Well, personally, I'm in favor of either TRUNCATE or ALTER
MATERIALIZED VIEW ... DISCARD. I think it's a dangerous
precedent to suppose that we're going to start using DISCARD for
things that have
On 1/31/13 2:18 PM, Alvaro Herrera wrote:
My intention was to apply a Nasby correction to Browne Strength and call
the resulting function Browne' (Browne prime). Does that sound better?
I suggest painting that bikeshed Browneby. :P
--
Sent via pgsql-hackers mailing list
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Robert Haas escribió:
I venture to guess that this is exactly the sort of thing that made
Tom argue upthread that we shouldn't be putting a firing point in the
middle of the drop operation. Any slip-ups here will result in
corrupt catalogs, and
On Thu, Feb 28, 2013 at 2:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Robert Haas escribió:
I venture to guess that this is exactly the sort of thing that made
Tom argue upthread that we shouldn't be putting a firing point in the
middle of the
Tom Lane escribió:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Robert Haas escribi�:
I venture to guess that this is exactly the sort of thing that made
Tom argue upthread that we shouldn't be putting a firing point in the
middle of the drop operation. Any slip-ups here will result
Robert Haas escribió:
On Thu, Feb 28, 2013 at 2:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Maybe down the road we'll conclude that there's no other way and we're
willing to put up with an unsafe feature, but I don't want to take that
step
I looked into the behavior complained of in
http://www.postgresql.org/message-id/CAMkU=1xliwdkfemkdwjznr_jmzuybzzrz4f22kxa3vg6pz9...@mail.gmail.com
I'm still not sure whether anything else is going on in the original
problem, but I now understand Jeff's simplified query. The planner
does actually
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Robert Haas escribió:
It seems to me that a better way to do this might be to look up the
names of all the objects being dropped, as we get rid of them, and
pass that information off to the ddl_command_end trigger via something
like the
Today's b^Hdiscussion on materialized views reminded me that I spent a
little bit of time looking at gram.y and thinking about what we might
be able to do to reduce the amount of bloat it spits out. On my
system, without debugging symbols, gram.o is 1019260 bytes. Using nm
gram.o | sort | less
Robert Haas robertmh...@gmail.com writes:
A whole lot of those state transitions are attributable to states
which have separate transitions for each of many keywords.
Yeah, that's no surprise.
The idea that's been in the back of my mind for awhile is to try to
solve the problem at the lexer
Tom Lane t...@sss.pgh.pa.us writes:
I think it's fairly obvious that
(1) dealing with a DROP only after it's happened is pretty limiting;
(2) allowing user-defined code to run mid-command is dangerous.
What's at issue is the tradeoff we make between these inescapable
facts, and I'm not sure
On 02/28/2013 11:37 AM, Jeff Janes wrote:
Did you copy libpq.dll from the lib directory to the bin
directory? If not, try that and see if it fixes the problem.
I've now done that, and it did fix the problem. I can start the
database with pg_ctl.exe if I want.
Should the
Dimitri Fontaine escribió:
Tom Lane t...@sss.pgh.pa.us writes:
I think it's fairly obvious that
(1) dealing with a DROP only after it's happened is pretty limiting;
(2) allowing user-defined code to run mid-command is dangerous.
What's at issue is the tradeoff we make between these
On Thu, Feb 28, 2013 at 3:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think it's fairly obvious that
(1) dealing with a DROP only after it's happened is pretty limiting;
(2) allowing user-defined code to run mid-command is dangerous.
What's at issue is the tradeoff we make between these
On 13-02-25 05:37 PM, Andrew Dunstan wrote:
On 02/24/2013 01:09 AM, Steve Singer wrote:
On 13-01-11 11:03 AM, Andrew Dunstan wrote:
On 01/11/2013 11:00 AM, Andrew Dunstan wrote:
I have not had anyone follow up on this, so I have added docs and
will add this to the commitfest.
Recap:
On Tue, Feb 26, 2013 at 3:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm inclined to think the right fix is to make a small memory context
for each prepared plan made by plperl_spi_prepare(). The qdesc for it
could be made right in the context (getting rid of the unchecked
malloc's near the
Phil Sorber wrote:
On Wed, Feb 13, 2013 at 5:48 PM, Josh Berkus j...@agliodbs.com wrote:
On 02/13/2013 02:13 PM, Tom Lane wrote:
The big-picture question of course is whether we want to carry and
maintain a filesystem-specific hack. I don't have a sense that btrfs
is so widely used as to
32 matches
Mail list logo
