Phil Sorber wrote:
> On Wed, Feb 13, 2013 at 5:48 PM, Josh Berkus 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 justify t
On Tue, Feb 26, 2013 at 3:56 PM, Tom Lane 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 top of the func
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:
Thi
On Thu, Feb 28, 2013 at 3:20 PM, Tom Lane 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 inescapable
> facts,
Dimitri Fontaine escribió:
> Tom Lane 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
> >
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 makefil
Tom Lane 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 if we can get c
Robert Haas 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 level not the parser l
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 t
Alvaro Herrera 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 pg_dropped_objects() fun
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
Robert Haas escribió:
> On Thu, Feb 28, 2013 at 2:14 PM, Tom Lane wrote:
> > Alvaro Herrera 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 under time pressure to ship somethin
Tom Lane escribió:
> Alvaro Herrera 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
> >> corrup
On Thu, Feb 28, 2013 at 2:14 PM, Tom Lane wrote:
> Alvaro Herrera 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
Alvaro Herrera 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 it's not exactl
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 (pgsql-hackers@post
Heikki Linnakangas 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 nothing to do with
Robert Haas escribió:
> On Thu, Feb 21, 2013 at 12:52 PM, Alvaro Herrera
> 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 attributes are not
On Thu, Feb 28, 2013 at 11:00 AM, Tom Lane 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 existing meanin
Changed subject from "Strange Windows problem, lock_timeout test request"
On Thu, Jan 24, 2013 at 11:41 AM, Andrew Dunstan wrote:
>
> On 01/24/2013 01:44 PM, Jeff Janes wrote:
>
>> On Sat, Jan 19, 2013 at 12:15 PM, Andrew Dunstan
>> wrote:
>>
>>> On 01/19/2013 02:36 AM, Boszormenyi Zoltan wrote:
On 28.02.2013 16:55, Robert Haas wrote:
On Sat, Feb 23, 2013 at 8:00 AM, Michael Paquier
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 d
Robert Haas writes:
> On Sat, Feb 23, 2013 at 8:00 AM, Michael Paquier
> 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 p
On 28 February 2013 11:25, Kyotaro HORIGUCHI
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?
>
Sorry, I've been mean
On Sat, Feb 23, 2013 at 8:00 AM, Michael Paquier
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 precedent to
suppose that we're
On Thu, Feb 28, 2013 at 3:21 PM, Michael Paquier
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 problem in the latest pa
On Thu, Feb 28, 2013 at 2:29 AM, Heikki Linnakangas
wrote:
> On 26.02.2013 19:42, Tom Lane wrote:
>>
>> Fujii Masao writes:
>>>
>>> In HEAD, when I ran "pg_basebackup -D hoge -X stream",
>>> I got the following FailedAssertion error:
>>
>>
>>> TRAP: FailedAssertion("!((wakeEvents& ((1<< 1) | (1
Hello
I have no objections,
Thank you for update
Regards
Pavel
2013/2/28 Kyotaro HORIGUCHI :
> 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 behavior and to mimic the
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 maili
ber of the elements of it. If that's not your
intent, some rewrite would be needed..
- Only int4 is directly read for width value in the latest
patch, but int2 can also be directly readable and it should
be needed.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
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 w
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 swam
On Thu, Feb 28, 2013 at 4:56 PM, anara...@anarazel.de wrote:
> Hi,
>
> Michael Paquier 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 existing patches.
>
> I think the
32 matches
Mail list logo
