On Fri, 2009-09-04 at 01:25 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Thu, 2009-09-03 at 22:22 +0300, Heikki Linnakangas wrote:
> >> Simon Riggs wrote:
> >>> I propose we just accept that both max_connections and
> >>> max_prepared_transactions need to be set correctly for recovery to w
Simon Riggs writes:
> On Thu, 2009-09-03 at 22:22 +0300, Heikki Linnakangas wrote:
>> Simon Riggs wrote:
>>> I propose we just accept that both max_connections and
>>> max_prepared_transactions need to be set correctly for recovery to work.
>>> This will make the state transitions more robust and
2009/9/3 Pavel Stehule :
> 2009/9/3 Joshua Tolley :
>> On Thu, Sep 03, 2009 at 01:19:25AM +0400, Олег Царев wrote:
>>> After week-lengthed investigation, now i 'm sure - my level of
>>> qualification not enough for implementation task "GROUPING SETS".
>>> I require documentation about the executor
2009/9/4 Joshua D. Drake :
> On Thu, 2009-09-03 at 12:00 -0400, Robert Haas wrote:
>> And /me pokes Brendan Jurd. :-)
>>
>
> Hah! I almost listed him. /me adds a poke to Brendan Jurd.
>
/me stirs from sleep to announce "huh? whaddyawant?"
Seriously though, I have been keeping an eye on this thre
Robert Haas wrote:
> 2009/9/3 KaiGai Kohei :
>> KaiGai Kohei wrote:
>>> Alvaro Herrera wrote:
Tom Lane wrote:
> KaiGai Kohei writes:
>> BTW, currently, the default ACL of largeobject allows anything for owner
>> and nothing for world. Do you have any comment for the default behavi
2009/9/3 KaiGai Kohei :
> KaiGai Kohei wrote:
>> Alvaro Herrera wrote:
>>> Tom Lane wrote:
KaiGai Kohei writes:
> BTW, currently, the default ACL of largeobject allows anything for owner
> and nothing for world. Do you have any comment for the default behavior?
Mph. I think the
KaiGai Kohei wrote:
> Alvaro Herrera wrote:
>> Tom Lane wrote:
>>> KaiGai Kohei writes:
BTW, currently, the default ACL of largeobject allows anything for owner
and nothing for world. Do you have any comment for the default behavior?
>>> Mph. I think the backlash will be too great. You
Peter Eisentraut wrote:
> The SQL standard specifies that a trigger is fired if the column is
> mentioned in the UPDATE statement, independent of whether the value is
> actually changed through the update.
Hmmm, what does the SQL standard say about modification of NEW values?
Should we fire col
Attached is a patch to add a couple basic dependency look-up capability
functions. They're based off the pg_get_serial_sequence function, and
are kind of the inverse of that function in some respects.
The patch adds two new functions to the backend, pg_get_owner_object and
pg_get_owner_column. T
* Joshua D. Drake (j...@commandprompt.com) wrote:
> She would definitely be a good option if she has time. I know that I
> would be interested and I would like to see at least one long time
> -hacker on board.
I don't presume to be a long time -hacker, but I'm interested in what I
can do to help w
On Thu, Sep 03, 2009 at 07:57:25PM -0400, Andrew Dunstan wrote:
> daveg wrote:
> >On Tue, Sep 01, 2009 at 07:42:56PM -0400, Tom Lane wrote:
> >>I'm having a hard time believing that VACUUM FULL really has any
> >>interesting use-case anymore.
> >
> >I have a client who uses temp tables heavily, hun
daveg wrote:
On Tue, Sep 01, 2009 at 07:42:56PM -0400, Tom Lane wrote:
Greg Stark writes:
On Wed, Sep 2, 2009 at 12:01 AM, Alvaro
Herrera wrote:
The use cases where VACUUM FULL wins currently are where storing two
copies of the table and its indexes concurrently just isn't pr
On Tue, Sep 01, 2009 at 07:42:56PM -0400, Tom Lane wrote:
> Greg Stark writes:
> > On Wed, Sep 2, 2009 at 12:01 AM, Alvaro
> > Herrera wrote:
> >>> The use cases where VACUUM FULL wins currently are where storing two
> >>> copies of the table and its indexes concurrently just isn't practical.
> >>
On Thu, 2009-09-03 at 22:22 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > I propose we just accept that both max_connections and
> > max_prepared_transactions need to be set correctly for recovery to work.
> > This will make the state transitions more robust and it will avoid
> > spuri
>>> How about this: 6:00 Tuesday evening (Pacific), the three of us (and
>>> anybody else) agree to be around a table with laptops on, cellphones
>>> ready, listening at an IRC channel. Could you assign us good patches
>>> before then (like 10)? And then we commit, commit, commit.
>
> Sounds good,
Simon Riggs wrote:
> I propose we just accept that both max_connections and
> max_prepared_transactions need to be set correctly for recovery to work.
> This will make the state transitions more robust and it will avoid
> spurious and hard to test error messages.
>
> Any objections to me removing
On Thu, Sep 3, 2009 at 10:58 AM, Robert Haas wrote:
> On Thu, Sep 3, 2009 at 1:54 PM, Webb Sprague wrote:
>> Hi Josh et al,
>>
>> I believe we are all still interested (Selena? Gabrielle?)
Heck yes!
>> How about this: 6:00 Tuesday evening (Pacific), the three of us (and
>> anybody else) agree to
On Thu, Sep 3, 2009 at 11:27 AM, Tom Lane wrote:
> Josh Berkus writes:
>> Selena, Robert, Brendan, Kevin,
>> One of the ideas behind the Alpha releases was to give someone other
>> than the core team some practice doing releases.
>
> Uh, what's the point of that? The existing core team has that p
Peter Eisentraut writes:
> On tor, 2009-09-03 at 11:19 -0400, Robert Haas wrote:
>> Sure, but I don't think it makes a lot of sense to spend a lot of time
>> implementing the standard behavior unless someone can provide a
>> plausible use case.
> One use case is porting Oracle applications. I se
On Thu, Sep 3, 2009 at 2:27 PM, Tom Lane wrote:
> Josh Berkus writes:
>> Selena, Robert, Brendan, Kevin,
>> One of the ideas behind the Alpha releases was to give someone other
>> than the core team some practice doing releases.
>
> Uh, what's the point of that? The existing core team has that pr
Josh Berkus writes:
> Selena, Robert, Brendan, Kevin,
> One of the ideas behind the Alpha releases was to give someone other
> than the core team some practice doing releases.
Uh, what's the point of that? The existing core team has that process
perfectly well in hand. What I thought this discu
On Thu, Sep 3, 2009 at 11:02 AM, Webb Sprague wrote:
>> The CommitFest is scheduled to start 9/15, so doing this on 9/8 might
>> be a bit too soon. I wouldn't object to doing it a few days before
>> the start of the CommitFest to flush out any patches with obvious
>> problems, but I think a week a
We discussed earlier that HS should continue to work even if
max_connections was set differently on the primary and the standby. This
now gives a situation where snapshots can be allowed, then disallowed
for a while, then allowed again.
Complication is that this will cause some connections to fai
On Thu, Sep 3, 2009 at 2:16 PM, Peter Eisentraut wrote:
> On tor, 2009-09-03 at 11:19 -0400, Robert Haas wrote:
>> Sure, but I don't think it makes a lot of sense to spend a lot of time
>> implementing the standard behavior unless someone can provide a
>> plausible use case.
>
> One use case is por
On tor, 2009-09-03 at 11:19 -0400, Robert Haas wrote:
> Sure, but I don't think it makes a lot of sense to spend a lot of time
> implementing the standard behavior unless someone can provide a
> plausible use case.
One use case is porting Oracle applications. I see a lot of that used
there. The
> The CommitFest is scheduled to start 9/15, so doing this on 9/8 might
> be a bit too soon. I wouldn't object to doing it a few days before
> the start of the CommitFest to flush out any patches with obvious
> problems, but I think a week ahead of time is too much.
Yeah, I meant Tues 9/15.
> Al
On Thu, Sep 3, 2009 at 1:54 PM, Webb Sprague wrote:
> Hi Josh et al,
>
> I believe we are all still interested (Selena? Gabrielle?)
>
> How about this: 6:00 Tuesday evening (Pacific), the three of us (and
> anybody else) agree to be around a table with laptops on, cellphones
> ready, listening at a
Hi Josh et al,
I believe we are all still interested (Selena? Gabrielle?)
How about this: 6:00 Tuesday evening (Pacific), the three of us (and
anybody else) agree to be around a table with laptops on, cellphones
ready, listening at an IRC channel. Could you assign us good patches
before then (lik
On Thu, Sep 03, 2009 at 01:26:52PM -0400, Tom Lane wrote:
> David Fetter writes:
> > On Thu, Sep 03, 2009 at 10:24:17AM -0400, Tom Lane wrote:
> >> While s390x is still not quite mainstream, at least I can get
> >> access to one ;-).
>
> > Do you also have access to z/OS with Unix System Services
Josh Berkus wrote:
> So I think it would make sense for you guys to do Alpha2.
I'm not really clear on what that means. I'm assuming that part of
the goal is for us to become more intimately familiar with the details
of putting together a release, documenting the process, and suggesting
possi
On Thu, Sep 3, 2009 at 10:21 AM, Josh Berkus wrote:
> Selena, Robert, Brendan, Kevin,
>
> One of the ideas behind the Alpha releases was to give someone other
> than the core team some practice doing releases.
>
> So I think it would make sense for you guys to do Alpha2. Agreed, Peter?
I'm up for
David Fetter writes:
> On Thu, Sep 03, 2009 at 10:24:17AM -0400, Tom Lane wrote:
>> While s390x is still not quite mainstream, at least I can get
>> access to one ;-).
> Do you also have access to z/OS with Unix System Services?
No, Red Hat's machines run RHEL ;-)
>> What I am thinking is that
On Thu, Sep 3, 2009 at 1:21 PM, Josh Berkus wrote:
> Selena, Robert, Brendan, Kevin,
>
> One of the ideas behind the Alpha releases was to give someone other
> than the core team some practice doing releases.
>
> So I think it would make sense for you guys to do Alpha2. Agreed, Peter?
I have no i
On Thu, 2009-09-03 at 10:21 -0700, Josh Berkus wrote:
> Selena, Robert, Brendan, Kevin,
>
> One of the ideas behind the Alpha releases was to give someone other
> than the core team some practice doing releases.
>
> So I think it would make sense for you guys to do Alpha2. Agreed, Peter?
I thin
Webb, Selena, Gabrielle,
September 15th is coming up soon. Will PDXPUG be interested in doing a
CommitFest Sprint? When can you do it?
Let me know, because we'll want to have the sprinters claim patches early.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hacker
Selena, Robert, Brendan, Kevin,
One of the ideas behind the Alpha releases was to give someone other
than the core team some practice doing releases.
So I think it would make sense for you guys to do Alpha2. Agreed, Peter?
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via
iog...@free.fr escribió:
> A simple use case would be to update a timestamp column with
> CURRENT_TIMESTAMP as instance.
No, because you want to update the timestamp in all cases, whatever
columns the update actually updates.
--
Alvaro Herrerahttp://www.CommandPr
On Thu, Sep 03, 2009 at 10:24:17AM -0400, Tom Lane wrote:
> We have seen several previous reports of regression test failures
> due to division by zero causing SIGFPE, even though the code should
> never reach the division command:
>
> http://archives.postgresql.org/pgsql-bugs/2006-11/msg00180.php
On Thu, 3 Sep 2009, Robert Haas wrote:
On Thu, Sep 3, 2009 at 9:51 AM, Peter Eisentraut wrote:
On Thu, 2009-09-03 at 07:57 -0400, Robert Haas wrote:
On Sep 3, 2009, at 7:44 AM, Peter Eisentraut wrote:
The SQL standard specifies that a trigger is fired if the column is
mentioned in the UPDATE
On Thu, Sep 3, 2009 at 9:00 AM, Robert Haas wrote:
> Yeah, I'm game, though I'm hoping not to become the guy who spends all
> his time doing release planning, because I like writing code, too.
> Hopefully Selena won't mind my mentioning that she sent me a private
> email expressing some interest i
"Joshua D. Drake" wrote:
> /me pokes Robert Haas and Kevin Grittner
I'm honored to be suggested for such a role. I'm happy to do what I
can, but am reluctant to put myself too squarely in any critical path,
as I have responsibility for dealing with some family health issues
which make unpredi
On Thu, 2009-09-03 at 12:00 -0400, Robert Haas wrote:
> > O.k. so the second part of this, is I feel it should contain a majority
> > of people who are not already being slammed into the ground by community
> > work. E.g; let's get some fresh blood. It is certainly important to have
> > a couple o
On Thu, Sep 3, 2009 at 11:55 AM, Joshua D. Drake wrote:
> On Thu, 2009-09-03 at 11:41 -0400, Robert Haas wrote:
>> On Thu, Sep 3, 2009 at 11:38 AM, Joshua D. Drake
>> wrote:
>> > On Thu, 2009-09-03 at 07:44 +0300, Peter Eisentraut wrote:
>> >> On ons, 2009-09-02 at 12:52 -0700, Joshua D. Drake wro
On Thu, 2009-09-03 at 11:41 -0400, Robert Haas wrote:
> On Thu, Sep 3, 2009 at 11:38 AM, Joshua D. Drake
> wrote:
> > On Thu, 2009-09-03 at 07:44 +0300, Peter Eisentraut wrote:
> >> On ons, 2009-09-02 at 12:52 -0700, Joshua D. Drake wrote:
> >> > Isn't "core" supposed to be the release manager?
>
On Thu, Sep 3, 2009 at 11:38 AM, Joshua D. Drake wrote:
> On Thu, 2009-09-03 at 07:44 +0300, Peter Eisentraut wrote:
>> On ons, 2009-09-02 at 12:52 -0700, Joshua D. Drake wrote:
>> > Isn't "core" supposed to be the release manager?
>>
>> The core team has historically been the release *maker* and h
On Thu, 2009-09-03 at 07:44 +0300, Peter Eisentraut wrote:
> On ons, 2009-09-02 at 12:52 -0700, Joshua D. Drake wrote:
> > Isn't "core" supposed to be the release manager?
>
> The core team has historically been the release *maker* and has some
> done management of the final phases of that process
On Thu, Sep 3, 2009 at 10:37 AM, Peter Eisentraut wrote:
> On Thu, 2009-09-03 at 10:24 -0400, Robert Haas wrote:
>> If TRIGGER ON UPDATE OF foo_id means whether the value actually
>> changed, then I can skip the check. If TRIGGER ON UPDATE OF foo_id
>> means whether the column was present in the u
Robert Haas wrote:
On Wed, Sep 2, 2009 at 9:52 PM, Itagaki
Takahiro wrote:
Here is a patch to implement "Support triggers on columns" in our ToDo list.
The syntax is:
CREATE TRIGGER name
BEFORE UPDATE OF col1, col12, ...
ON tbl FOR EACH ROW EXECUTE PROCEDURE func();
I con
Hi,
Robert Haas writes:
> By the way, I completely agree that it would be useful to have a way
> to suppress triggers from firing when no columns were actually
> modified.
http://www.postgresql.org/docs/8.4/static/functions-trigger.html
Currently PostgreSQL provides one built in trigger f
Robert Haas wrote:
> It also seems to me logically inconsistent that we would expose this
> information via the CREATE TRIGGER interface but not to the trigger
> function itself. From within the function, you can compare NEW and
> OLD, but you get no visibility into which columns were actually
On Thu, 2009-09-03 at 10:24 -0400, Robert Haas wrote:
> If TRIGGER ON UPDATE OF foo_id means whether the value actually
> changed, then I can skip the check. If TRIGGER ON UPDATE OF foo_id
> means whether the column was present in the update list, then it
> doesn't. Perhaps there are some use cas
Itagaki Takahiro writes:
> Is it reasonable to replace relation_open() calls to try_relation_open() ?
I don't think so; that's just papering over one form of the problem,
and who's to say that an error is not desirable when a wrong OID is
given? In general there's always a risk of concurrency pr
On Thu, Sep 3, 2009 at 9:51 AM, Peter Eisentraut wrote:
> On Thu, 2009-09-03 at 07:57 -0400, Robert Haas wrote:
>> On Sep 3, 2009, at 7:44 AM, Peter Eisentraut wrote:
>> > The SQL standard specifies that a trigger is fired if the column is
>> > mentioned in the UPDATE statement, independent of whe
We have seen several previous reports of regression test failures
due to division by zero causing SIGFPE, even though the code
should never reach the division command:
http://archives.postgresql.org/pgsql-bugs/2006-11/msg00180.php
http://archives.postgresql.org/pgsql-bugs/2007-11/msg00032.php
http
Hello
defaults are supported in 8.4
regards
Pavel Stehule
2009/9/3 Sergey Konoplev :
>> IMHO convenient solution is to make possible to specify something like
>> COLUMN_DEFAULT as input value of function.
>>
>> I wonder if it's possible.
>>
>
> So, what do you think of it?
>
> --
> Regards,
> Se
On Thu, 2009-09-03 at 07:57 -0400, Robert Haas wrote:
> On Sep 3, 2009, at 7:44 AM, Peter Eisentraut wrote:
> > The SQL standard specifies that a trigger is fired if the column is
> > mentioned in the UPDATE statement, independent of whether the value is
> > actually changed through the update.
>
Boszormenyi Zoltan írta:
> Alvaro Herrera írta:
>
>> Boszormenyi Zoltan wrote:
>>
>>
>>
>>> The vague consensus for syntax options was that the GUC
>>> 'lock_timeout' and WAIT [N] extension (wherever NOWAIT
>>> is allowed) both should be implemented.
>>>
>>> Behaviour would be that N sec
Hi,
we have updated our patchset to current 8.5 CVS.
The actual patches will be in emails coming as
answers to this one. As two patches were already included,
the remaining patches are as follows:
1. dynamic cursorname
2. sqlda support
3. describe support
4. proper out-of-scope declare/open/fetch
Hi.
I hope, that this is right mailing list.
SELECT date, value FROM t_event
WHERE t_event.id in (SELECT id FROM t_event
WHERE date < '2009-08-25'
ORDER BY date DESC LIMIT 1)
ORDER BY date;
cost 6.4
SELECT date, value FROM t_event
WHERE t_e
On Sep 3, 2009, at 7:44 AM, Peter Eisentraut wrote:
On Thu, 2009-09-03 at 16:25 +0900, Itagaki Takahiro wrote:
I'd like to check conditions by comparing actual values but not
a target of UPDATE statement because I think almost user expects
the former behavior. Unmodified UPDATE-targets are com
On Thu, 2009-09-03 at 16:25 +0900, Itagaki Takahiro wrote:
> I'd like to check conditions by comparing actual values but not
> a target of UPDATE statement because I think almost user expects
> the former behavior. Unmodified UPDATE-targets are common case
> if we use a framework that generates SQL
On Thu, Sep 3, 2009 at 13:31, Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
>>
>> Oh, hang on, "the NULL string" refers to the copy parameter? Not a
>> part of the data? I read it as "a string being NULL". Maybe something
>> like "the value of the NULL string parameter" to be overly clear for
Magnus Hagander wrote:
Oh, hang on, "the NULL string" refers to the copy parameter? Not a
part of the data? I read it as "a string being NULL". Maybe something
like "the value of the NULL string parameter" to be overly clear for
people like me? :-)
We could change:
A NULL is output as
On Thu, Sep 3, 2009 at 13:19, Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
>>
>> Our documentation for COPY
>> (http://www.postgresql.org/docs/8.4/static/sql-copy.html) has the
>> following to say:
>> "
>> The CSV format has no standard way to distinguish a NULL value from
>> an empty string
Magnus Hagander wrote:
Our documentation for COPY
(http://www.postgresql.org/docs/8.4/static/sql-copy.html) has the
following to say:
"
The CSV format has no standard way to distinguish a NULL value from
an empty string. PostgreSQL's COPY handles this by quoting. A NULL is
output as the NULL s
> IMHO convenient solution is to make possible to specify something like
> COLUMN_DEFAULT as input value of function.
>
> I wonder if it's possible.
>
So, what do you think of it?
--
Regards,
Sergey Konoplev
--
PostgreSQL articles in english & russian
http://gray-hemp.blogspot.com/search/label/p
I received a trouble-report that a query using pg_relation_size()
ends with an error, "could not open relation". It came from
DROP TABLE was executed concurrently; relation_open() used in
pg_relation_size() raised an error.
Is it reasonable to replace relation_open() calls to try_relation_open()
Crap, I just realized I sent to pgadmin hackers by mystake. Meh.
Our documentation for COPY
(http://www.postgresql.org/docs/8.4/static/sql-copy.html) has the
following to say:
"
The CSV format has no standard way to distinguish a NULL value from
an empty string. PostgreSQL's COPY handles this b
KaiGai Kohei wrote:
> Itagaki-san, isn't it more suitable to check rte->modifiedCols
> than heap_tuple_attr_equals()? Although, this information is
> not delivered to executor...
I'd like to check conditions by comparing actual values but not
a target of UPDATE statement because I think almost
Tom Lane wrote:
> exactly how, and when, are you determining whether a column has
> been "modified"? I can't count the number of times somebody
> has proposed simplistic and incorrect solutions to that.
> Usually they forget about BEFORE triggers changing the row.
There are some approaches:
Tom Lane wrote:
> Itagaki Takahiro writes:
>> Sure, and I found there might be difference between "UPDATE" and
>> "UPDATE OF {all-columns}" triggers. UPDATE trigger is always fired
>> when a row is updated even if none of the columns are actually
>> modified, but UPDATE OF {all-columns} trigger is
Hi,
Hans-Juergen Schoenig -- PostgreSQL wrote:
> we did some experiments with doing such a table.
> the problem is if you want to allow arbitrary combinations of words
> which can be modeled perfectly with FTI.
> you would instantly end up with a self join with 5 relations or so -
> which is again
72 matches
Mail list logo
