On Mon, Mar 16, 2015 at 11:05 PM, Jeff Janes wrote:
> On Mon, Feb 23, 2015 at 8:56 AM, Heikki Linnakangas <
> hlinnakan...@vmware.com> wrote:
>
>>
>> Everyone seems to be happy with the names and behaviour of the GUCs, so
>> committed.
>
>
>
> The docs suggest that max_wal_size will be respected
On Wed, May 20, 2015 at 09:15:14AM -0400, Simon Riggs wrote:
> On 20 May 2015 at 03:13, Noah Misch wrote:
> > Brief committer appraisals are unhelpful individually, but patterns
> > matter. I
> > would make the questionnaire as simple as necessary to get 4-7 committer
> > evaluations per patch.
On Thu, May 14, 2015 at 01:38:49PM -0400, Tom Lane wrote:
> * The comments in the code betray utter ignorance of how logging actually
> works, in particular this:
>
> * Administrators can choose which log level the audit log is to be logged
> * at. The default level is LOG, which goes into the
On Mon, Mar 16, 2015 at 7:39 PM, Andres Freund wrote:
> On 2015-03-16 07:52:20 +, Simon Riggs wrote:
>> On 15 March 2015 at 22:38, Andres Freund wrote:
>>
>> > Sorry, I don't buy this. If I have "recovery_target_action = 'pause'" in
>> > the config file, I want it to pause.
>>
>> You want it
On Thu, Mar 12, 2015 at 11:53 PM, Andres Freund wrote:
> On 2015-03-12 15:52:02 +0100, Andres Freund wrote:
>> I guess what you actually intended to test was StandbyModeRequested?
>
> Err, EnableHotStandby.
Pushed the fix.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsq
On Thu, May 21, 2015 at 12:42 AM, Andres Freund wrote:
>
> On 2015-05-20 19:27:05 +0530, Amit Kapila wrote:
>
> > 13.
> > In function replorigin_session_setup() and or
> > replorigin_session_advance(), don't we need to WAL log the
> > use of Replication state?
>
> No, the point is that the replica
On 2015/05/20 22:59, Heikki Linnakangas wrote:
On 05/20/2015 12:40 PM, Etsuro Fujita wrote:
The attached patch fixes a typo in a comment in tablecmds.c.
Fixed, along with dozens more similar typos I found with some grepping.
Thanks for doint that completely!
Best regards,
Etsuro Fujita
--
On Wed, May 20, 2015 at 6:12 PM, Andres Freund wrote:
> You realize there's other instances of this in the same damn function?
I was misled by the argument name, "parsetree" -- in the past,
CreateCommandTag() actually only processed raw parse trees. Beyond
that, I wasn't aware that it is possible
On Wed, May 20, 2015 at 8:22 PM, Jim Nasby wrote:
>> It might be a good idea to do something like this, but it's
>> significantly more complicated than a protocol-level SET SESSION
>> AUTHORIZATION. Right now, you can never go backwards from an
>> authenticated state to an unauthenticated state,
On Wed, May 20, 2015 at 7:09 PM, Michael Banck wrote:
>> I think Andres' point about "trust" being an essential disaster recovery
>> mode is something to consider, as well. That puts pretty strict limits
>> on what would be a credible replacement.
>
> Then let's rename it from `trust' to `disaste
Jim Nasby wrote:
> BTW, is there a reason we're putting function SQL in that file other than it
> was a convenient place?
Probably not. I've looked at that file wondering the same thing a
number of times ...
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 2
On Wed, May 20, 2015 at 6:22 PM, Tom Lane wrote:
> I am not really sure that it was a good idea to invent
> this command tag. In fact, I'm pretty sure it was a *bad* idea ---
> what will happen if we ever create a statement actually named UPSERT?
Why would we invent a statement actually named UP
On 2015-05-20 21:22:08 -0400, Tom Lane wrote:
> Not to mention that several places in libpq/fe-exec.c should be
> taught about this new tag. And who-knows-what in other client-side
> libraries. I am not really sure that it was a good idea to invent
> this command tag. In fact, I'm pretty sure it
Andres Freund writes:
> You realize there's other instances of this in the same damn function?
Not to mention that several places in libpq/fe-exec.c should be
taught about this new tag. And who-knows-what in other client-side
libraries. I am not really sure that it was a good idea to invent
thi
On 2015-05-20 15:21:49 -0700, Peter Geoghegan wrote:
> On Wed, May 20, 2015 at 3:14 PM, Peter Geoghegan wrote:
> > I think you're right. The initial commit neglected to update that, and
> > only handled it from ProcessQuery(). So it works for PlannedStmts, not
> > raw parse trees.
>
> Attached pa
On 2015-05-20 20:38:51 -0400, Tom Lane wrote:
> Jim Nasby writes:
> > On 5/20/15 6:56 PM, Andres Freund wrote:
> >> On 2015-05-20 18:48:59 -0500, Jim Nasby wrote:
> >>> and generally if you want to terminate the connection there's easier
> >>> ways to do that then "SELECT pg_terminate_backend(pg_b
Jim Nasby writes:
> On 5/20/15 6:56 PM, Andres Freund wrote:
>> On 2015-05-20 18:48:59 -0500, Jim Nasby wrote:
>>> and generally if you want to terminate the connection there's easier
>>> ways to do that then "SELECT pg_terminate_backend(pg_backend_pid())".
>> Which would be what exactly? Say, yo
On 5/20/15 7:19 PM, Stephen Frost wrote:
* Andres Freund (and...@anarazel.de) wrote:
>On 2015-05-20 19:46:12 -0400, Stephen Frost wrote:
> >In other words, I agree with you that we can't simply get rid of 'trust'
> >without having another solution. I*do* believe that a real single-user
> >mod
On 5/20/15 6:56 PM, Andres Freund wrote:
On 2015-05-20 18:48:59 -0500, Jim Nasby wrote:
and generally if you want to terminate the connection there's easier
ways to do that then "SELECT pg_terminate_backend(pg_backend_pid())".
Which would be what exactly? Say, you're inside a security definer
On 5/20/15 3:31 PM, Robert Haas wrote:
On Wed, May 20, 2015 at 3:42 PM, Alvaro Herrera
wrote:
>Robert Haas wrote:
>After mulling over this a bit, I think that if we're to do something to
>improve things here we should redesign the protocol so that it considers
>poolers explicitely. Right now
* Andres Freund (and...@anarazel.de) wrote:
> On 2015-05-20 19:46:12 -0400, Stephen Frost wrote:
> > In other words, I agree with you that we can't simply get rid of 'trust'
> > without having another solution. I *do* believe that a real single-user
> > mode that is only available to the owner of
On 2015-05-20 19:46:12 -0400, Stephen Frost wrote:
> In other words, I agree with you that we can't simply get rid of 'trust'
> without having another solution. I *do* believe that a real single-user
> mode that is only available to the owner of the cluster would go a long
> way towards this goal.
On 5/20/15 3:09 PM, Tom Lane wrote:
Andres Freund writes:
On 2015-05-20 16:44:12 -0300, Alvaro Herrera wrote:
Andres Freund wrote:
Lots? As far as I can tell, this is the only Itanium machine in the
buildfarm.
...
(It's times like this that I regret not working for Red Hat any more,
and hav
On 2015-05-20 18:48:59 -0500, Jim Nasby wrote:
> and generally if you want to terminate the connection there's easier
> ways to do that then "SELECT pg_terminate_backend(pg_backend_pid())".
Which would be what exactly? Say, you're inside a security definer
function.
--
Sent via pgsql-hackers ma
* Michael Banck (mba...@gmx.net) wrote:
> On Wed, May 20, 2015 at 07:03:26PM -0400, Tom Lane wrote:
> > I think Andres' point about "trust" being an essential disaster recovery
> > mode is something to consider, as well. That puts pretty strict limits
> > on what would be a credible replacement.
>
On 5/20/15 11:15 AM, Jon Nelson wrote:
On Wed, May 20, 2015 at 9:09 AM, Tom Lane wrote:
I think backwards compatibility probably trumps that argument. I have
no objection to providing a different call that behaves this way, but
changing the behavior of existing applications will face a *much*
Andres,
* Andres Freund (and...@anarazel.de) wrote:
> On 2015-05-20 15:42:23 -0400, Stephen Frost wrote:
> > > So the first thing to establish is "other than Volker himself, who are
> > > we helping here?"
> >
> > I don't agree with this either. Providing a "bypass all authentication"
> > config
On 5/20/15 8:47 AM, Tom Lane wrote:
Jim Nasby writes:
On 5/19/15 9:19 PM, FabrÃzio de Royes Mello wrote:
+1 to add a second parameter to current functions.
Instead of allow_own_pid, I went with skip_own_pid. I have the function
still returning true even when it skips it's own PID... that s
On Wed, May 20, 2015 at 07:03:26PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > Michael Banck wrote:
> >> The other set of users I could think of are those who, for whatever
> >> reason, tend to always compile PostgreSQL from source for their
> >> company/organization. Maybe they have inte
Alvaro Herrera writes:
> Michael Banck wrote:
>> The other set of users I could think of are those who, for whatever
>> reason, tend to always compile PostgreSQL from source for their
>> company/organization. Maybe they have internal rules that requires a
>> custom installation prefix for all the
Michael Banck wrote:
> On Wed, May 20, 2015 at 02:10:30PM -0400, Tom Lane wrote:
> > One reason why it would not be, if it's a build-time decision,
> > is that it's quite unlikely that any popular packagers would build
> > that way. So this would only be applicable to custom-built binaries,
> > wh
On Wed, May 20, 2015 at 3:14 PM, Peter Geoghegan wrote:
> I think you're right. The initial commit neglected to update that, and
> only handled it from ProcessQuery(). So it works for PlannedStmts, not
> raw parse trees.
Attached patch fixes this. Thanks for the report.
--
Peter Geoghegan
diff
On Wed, May 20, 2015 at 02:10:30PM -0400, Tom Lane wrote:
> One reason why it would not be, if it's a build-time decision,
> is that it's quite unlikely that any popular packagers would build
> that way. So this would only be applicable to custom-built binaries,
> which is a pretty small class of
On Wed, May 20, 2015 at 3:09 PM, Alvaro Herrera
wrote:
>> Are you using an old psql? I thought that that would just result in no
>> command tag being displayed.
>
> Well, I'm using an editor to read the code of CreateCommandTag(), not
> executing anything. I guess that function needs an update, t
Peter Geoghegan wrote:
> On Wed, May 20, 2015 at 2:58 PM, Alvaro Herrera
> wrote:
> > Hm, I just realized that the command tag for INSERT ON CONFLICT is still
> > just INSERT. Is that okay? To me, the behavior is different enough
> > that it should have its own tag. I'm not too set on this, but
On Wed, May 20, 2015 at 2:58 PM, Alvaro Herrera
wrote:
> Hm, I just realized that the command tag for INSERT ON CONFLICT is still
> just INSERT. Is that okay? To me, the behavior is different enough
> that it should have its own tag. I'm not too set on this, but maybe
> others share this opinio
Andres Freund wrote:
> On 2015-05-20 15:42:23 -0400, Stephen Frost wrote:
> > > So the first thing to establish is "other than Volker himself, who are
> > > we helping here?"
> >
> > I don't agree with this either. Providing a "bypass all authentication"
> > configuration option really isn't a go
On 2015-05-20 18:58:16 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
>
> Hm, I just realized that the command tag for INSERT ON CONFLICT is still
> just INSERT. Is that okay? To me, the behavior is different enough
> that it sho
Andres Freund wrote:
> Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
Hm, I just realized that the command tag for INSERT ON CONFLICT is still
just INSERT. Is that okay? To me, the behavior is different enough
that it should have its own tag. I'm not too set on this, but maybe
others
On 2015-05-20 15:42:23 -0400, Stephen Frost wrote:
> > So the first thing to establish is "other than Volker himself, who are
> > we helping here?"
>
> I don't agree with this either. Providing a "bypass all authentication"
> configuration option really isn't a good thing. Why don't packagers us
Stephen Frost writes:
> I don't agree with this either. Providing a "bypass all authentication"
> configuration option really isn't a good thing. Why don't packagers use
> our default pg_hba.conf? Because it only makes sense in a development
> type of environment. I'd argue the same is true fo
Alvaro Herrera writes:
> Marko Tiikkaja wrote:
>> Any chance to get this fixed in time for 9.1.16?
> I hope you had pinged some days earlier. Here's a patch, but I will
> wait until this week's releases have been tagged before pushing.
BTW, I meant to update this thread but forgot until now: th
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I don't agree with this either. Providing a "bypass all authentication"
> > configuration option really isn't a good thing. Why don't packagers use
> > our default pg_hba.conf? Because it only makes sense in a development
On Wed, May 20, 2015 at 3:42 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> On Wed, May 20, 2015 at 11:27 AM, Marko Tiikkaja wrote:
>> > Now that we're on the topic of interesting things, would it make sense to
>> > add protocol support for a sort of a "re-authenticate"? So a pooler could
>>
Andrew Dunstan wrote:
> On 05/20/2015 03:34 PM, Tom Lane wrote:
>> The operator for tintervals can be traced back at least to
>> Postgres v4r2 (1994), which is the oldest tarball I have at
>> hand. Most of the current list are geometric operators that
>> were added by Tom Lockhart in 1997.
> W
Andres Freund writes:
> On 2015-05-20 16:44:12 -0300, Alvaro Herrera wrote:
>> Andres Freund wrote:
>>> Hm. Anole hasn't reported reliably for a while before these. It's quite
>>> possible that this is a ac++ portability problem around the
>>> atomics. There's lots of other IA64 animals not having
Andrew Dunstan writes:
> When did the SQL standard add any mention of ?
It's in SQL92. I don't have a copy of SQL89, or whatever the previous
spec was, to look at.
(So you could argue that Yu and Chen should've removed ? from the set of
allowed operator characters when they grafted SQL syntax o
On 05/20/2015 03:34 PM, Tom Lane wrote:
Dave Cramer writes:
Notably absent from the discussion is ODBC upon which JDBC was modelled and
probably predates any use of ? as an operator
It would be a mistake to imagine that operators containing '?' are some
johnny-come-lately. The operator fo
On 2015-05-20 16:44:12 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > Hm. Anole hasn't reported reliably for a while before these. It's quite
> > possible that this is a ac++ portability problem around the
> > atomics. There's lots of other IA64 animals not having problems, but
> > they're
Andres Freund wrote:
> On 2015-05-20 16:21:57 -0300, Alvaro Herrera wrote:
> > In HEAD only. Previous branches seem mostly clean, so there's something
> > going wrong. Spinlocks going wrong perhaps?
> >
> > http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=anole&dt=2015-05-20%2016%3A3
On 05/20/2015 03:37 PM, Tom Lane wrote:
Josh Berkus writes:
That does cover all bases, and users would be able to create the
operator which suits their particular use case easily. It's also fairly
similar to how jsquery works, although the syntax is completely different.
But ... it's after fe
On 2015-05-20 15:37:15 -0400, Tom Lane wrote:
> Josh Berkus writes:
> > That does cover all bases, and users would be able to create the
> > operator which suits their particular use case easily. It's also fairly
> > similar to how jsquery works, although the syntax is completely different.
>
>
Robert Haas wrote:
> On Wed, May 20, 2015 at 11:27 AM, Marko Tiikkaja wrote:
> > Now that we're on the topic of interesting things, would it make sense to
> > add protocol support for a sort of a "re-authenticate"? So a pooler could
> > first say "this user wants to log in from this host", then
* Josh Berkus (j...@agliodbs.com) wrote:
> On 05/20/2015 11:10 AM, Tom Lane wrote:
> > Alvaro Herrera writes:
> >> The proposal here is to have a configure argument that disables
> >> arbitrary auth mechanisms. How is that specific to a particular
> >> environment?
> >
> > I think Josh's questio
On 2015-05-20 16:21:57 -0300, Alvaro Herrera wrote:
> In HEAD only. Previous branches seem mostly clean, so there's something
> going wrong. Spinlocks going wrong perhaps?
>
> http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=anole&dt=2015-05-20%2016%3A30%3A26&stg=check
> ! PANIC: st
Josh Berkus writes:
> That does cover all bases, and users would be able to create the
> operator which suits their particular use case easily. It's also fairly
> similar to how jsquery works, although the syntax is completely different.
> But ... it's after feature freeze. So, thoughts?
I thi
Dave Cramer writes:
> Notably absent from the discussion is ODBC upon which JDBC was modelled and
> probably predates any use of ? as an operator
It would be a mistake to imagine that operators containing '?' are some
johnny-come-lately. The operator for tintervals can be traced back
at least
On Wed, May 20, 2015 at 11:27 AM, Marko Tiikkaja wrote:
> On 5/20/15 5:21 PM, Robert Haas wrote:
>> On Tue, May 19, 2015 at 5:02 PM, Simon Riggs
>> wrote:
>>> That's a reasonable argument. So +1 to protocol from me.
>>>
>>> To satisfy Tom, I think this would need to have two modes: one where the
In HEAD only. Previous branches seem mostly clean, so there's something
going wrong. Spinlocks going wrong perhaps?
http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=anole&dt=2015-05-20%2016%3A30%3A26&stg=check
! PANIC: stuck spinlock (cd6f4140) detected at lwlock.c:816
! ser
It is like bugfix than new feature
Dne 20.5.2015 21:08 napsal uživatel "Josh Berkus" :
> On 05/20/2015 11:34 AM, Andrew Dunstan wrote:
> > So Dmitry, at my suggestion, has come up with a way of doing that, by
> > adding a parameter to jsonb_replace(). If this parameter is set to true
> > (it defau
> "Tom" == Tom Lane writes:
>> I was thinking it should produce NUMERIC rather than int4 as it does
>> now in order to accommodate large numbers of columns, but the
>> usefulness of the bitmap is greatly increased if there's a simple
>> CAST to bit(n).
Tom> Maybe INT8 would be a better
On Wed, May 20, 2015 at 11:26 AM, Andres Freund wrote:
> Even if maybe not directly under the guise of exclusion constraints
> themselves, but I do think it's an interesting way to more easily allow
> to implement unique constraints on !amcanunique type indexes. Or, more
> interestingly, for uniq
Hi,
Thanks for looking through this!
On 2015-05-20 19:27:05 +0530, Amit Kapila wrote:
> 5.
> origin.c
>
> * * To create and drop replication origins an exclusive lock on
> * pg_replication_slot is required for the
> duration. That allows us to
> * safely and conflict free assign new origin
On 05/20/2015 11:10 AM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Josh Berkus wrote:
>>> As such, proposals are more likely to be successful if the proposer can
>>> show how they apply to a general use case, or adapt them so that they
>>> are useful to a large number of our users. This means th
On 2015-05-20 12:07:56 -0700, Peter Geoghegan wrote:
> You're talking about exclusion constraints as an implementation detail
> of something interesting, which I had not considered.
I did mention those two usecases a bunch of times... ;)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
On 05/20/2015 11:34 AM, Andrew Dunstan wrote:
> So Dmitry, at my suggestion, has come up with a way of doing that, by
> adding a parameter to jsonb_replace(). If this parameter is set to true
> (it defaults to false) and the key or array element pointed to by the
> last element of the path doesn't
Dave Cramer writes:
> Back to the issue at hand. Does anyone have a recommendation for a
> replacement operator besides ?
The bikeshedding potential here might be the worst part of the whole
thing. Still, if we can agree on reasonable substitute names, I wouldn't
be against it, even with the hug
On Wed, May 20, 2015 at 5:46 PM, Robert Haas wrote:
> I think we should be more focused on this part of the issue. It seems
> to me that it's a good idea for connectors to have an escaping
> mechanism. Pretty much any syntax that supports funny characters that
> do magical things should also ha
Hi,
On 2015-05-20 12:22:34 +0300, Uriy Zhuravlev wrote:
> On Monday 18 May 2015 10:21:10 you wrote:
> > difficulty of updating existing cached plans
> Could you specify more precisely about some caches we talking about? PREPARE
> working correctly:
>
> CREATE TABLE test_ints(i int4);
> CREATE TA
Alvaro Herrera writes:
> Uriy Zhuravlev wrote:
>> And can you explain more about the syntax?
> I think he means to treat COMMUTATOR etc like a generic element list,
> i.e. don't define new keywords in kwlist.h/gram.y at all but rather pass
> the names as strings (probably using a list of DefElem)
On Wed, May 20, 2015 at 12:34 PM, Andrew Dunstan
wrote:
>
> So Dmitry, at my suggestion, has come up with a way of doing that, by
> adding a parameter to jsonb_replace(). If this parameter is set to true (it
> defaults to false) and the key or array element pointed to by the last
> element of the
David Fetter writes:
> While kicking the tires on the new GROUPING() feature, I noticed that
> NUMERIC has no cast to bit(n). GROUPING() produces essentially a
> bitmap, although the standard mandates for some reason that it be a
> numeric type.
> I was thinking it should produce NUMERIC rather
Petr Jelinek wrote:
> On 20/05/15 01:38, Jim Nasby wrote:
> >If we get this wrong now, we'll be stuck with it forever. At a minimum I
> >think we should use anything other than || until we can figure this out.
> >That leaves || available for whichever case we decide on.
>
> I am of strong opinion
Uriy Zhuravlev wrote:
> And can you explain more about the syntax?
I think he means to treat COMMUTATOR etc like a generic element list,
i.e. don't define new keywords in kwlist.h/gram.y at all but rather pass
the names as strings (probably using a list of DefElem) and strcmp()
them in OperatorUp
On 05/20/2015 02:11 AM, Peter Geoghegan wrote:
On Tue, May 19, 2015 at 10:43 PM, Petr Jelinek wrote:
I am of strong opinion that concat should be shallow by default. Again it's
how jquery works by default, it's how python's dict.update works and you can
find this behavior in other languages as
On Wed, May 20, 2015 at 11:13 AM, Tom Lane wrote:
> Jeff Janes writes:
> > What if something like this was made to work?
> > select '{"3":5}'::jsonb operator("pg_catalog"."?") '3';
> > (Where the double quotes around the ? would be tolerated, which they
> > currently are not)
>
> > Is there a r
On 2015-05-20 11:24:06 -0700, Peter Geoghegan wrote:
> On Wed, May 20, 2015 at 10:37 AM, Andres Freund wrote:
> > But you *can* use a exclusion constraint for DO NOTHING. Just not (yet)
> > for DO UPDATE.
>
> FWIW, I don't think exclusion constraint DO UPDATE support is ever
> going to be useful.
On Wed, May 20, 2015 at 10:37 AM, Andres Freund wrote:
> But you *can* use a exclusion constraint for DO NOTHING. Just not (yet)
> for DO UPDATE.
FWIW, I don't think exclusion constraint DO UPDATE support is ever
going to be useful.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list
Jeff Janes writes:
> What if something like this was made to work?
> select '{"3":5}'::jsonb operator("pg_catalog"."?") '3';
> (Where the double quotes around the ? would be tolerated, which they
> currently are not)
> Is there a reason it can't be made to work?
It could be made to work, I'm su
On Wed, May 20, 2015 at 7:04 PM, Jeff Janes wrote:
>
> What if something like this was made to work?
>
> select '{"3":5}'::jsonb operator("pg_catalog"."?") '3';
>
> (Where the double quotes around the ? would be tolerated, which they
> currently are not)
>
> Is there a reason it can't be made to
Alvaro Herrera writes:
> Josh Berkus wrote:
>> As such, proposals are more likely to be successful if the proposer can
>> show how they apply to a general use case, or adapt them so that they
>> are useful to a large number of our users. This means that "this works
>> in our environment which has
On Wed, May 20, 2015 at 1:06 PM, alejandro wrote:
> hello, my partner and me are working with the goal of improve the GEQO's
> performance, we tried with Ant Colony Optimization, but it does not improve,
> actually we are trying with a new variant of Genetic Algorithm, specifically
> Micro-GA. Thi
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Josh Berkus wrote:
>
> > As such, proposals are more likely to be successful if the proposer can
> > show how they apply to a general use case, or adapt them so that they
> > are useful to a large number of our users. This means that "this work
hello, my partner and me are working with the goal of improve the GEQO's
performance, we tried with Ant Colony Optimization, but it does not improve,
actually we are trying with a new variant of Genetic Algorithm, specifically
Micro-GA. This algorithm finds a better solution than GEQO in less time,
Folks,
While kicking the tires on the new GROUPING() feature, I noticed that
NUMERIC has no cast to bit(n). GROUPING() produces essentially a
bitmap, although the standard mandates for some reason that it be a
numeric type.
I was thinking it should produce NUMERIC rather than int4 as it does
now
On Fri, May 15, 2015 at 1:23 PM, Dave Cramer wrote:
>
>
>
> On 15 May 2015 at 16:21, Robert Haas wrote:
>
>> On Fri, May 15, 2015 at 4:13 PM, Dave Cramer wrote:
>> > Not sure what the point of this is: as you indicated the ship has
>> sailed so
>> > to speak
>>
>> Well, if we were to agree this
Josh Berkus wrote:
> As such, proposals are more likely to be successful if the proposer can
> show how they apply to a general use case, or adapt them so that they
> are useful to a large number of our users. This means that "this works
> in our environment which has conditions X, Y, and Z" is n
Andres Freund writes:
> On 2015-05-20 13:31:57 -0400, Tom Lane wrote:
>> If you can't use an exclusion constraint to support the command,
>> then the error message shouldn't be worded like that.
> But you *can* use a exclusion constraint for DO NOTHING. Just not (yet)
> for DO UPDATE.
Hm. Maybe
Tom Lane wrote:
> Heikki Linnakangas writes:
> > Thanks, committed. Except for this one:
>
> > - * *Only* a frozen-for-read tape can be seeked.
> > + * *Only* a frozen-for-read tape can be sought.
>
> > It's true that the past tense of "seek" is "sought", but it feels a bit
> > weird to me in t
On 2015-05-20 13:31:57 -0400, Tom Lane wrote:
> Sure, but on what basis does it decide that there's a conflict?
>
> If you can't use an exclusion constraint to support the command,
> then the error message shouldn't be worded like that.
But you *can* use a exclusion constraint for DO NOTHING. Jus
On 05/20/2015 01:20 AM, Volker Aßmann wrote:
So, in the interests of trying to get you to understand why your
proposal met with a negative response, and to improve future proposals:
> You don't seem to have much trust in your other authentication
> mechanisms and seem to know our environment quit
Andres Freund writes:
> On 2015-05-20 18:09:05 +0100, Thom Brown wrote:
This implies that an exclusion constraint is valid in the statement,
which contradicts the docs. Which one is correct?
>>> ON CONFLICT can be used for ... DO NOTHING as well.
>> Yes, but still confusing when not u
Heikki Linnakangas writes:
> Thanks, committed. Except for this one:
> - * *Only* a frozen-for-read tape can be seeked.
> + * *Only* a frozen-for-read tape can be sought.
> It's true that the past tense of "seek" is "sought", but it feels a bit
> weird to me in this context. This is a comment o
On 2015-05-20 18:09:05 +0100, Thom Brown wrote:
> On 20 May 2015 at 17:54, Andres Freund wrote:
> > On 2015-05-20 17:44:05 +0100, Thom Brown wrote:
> >> The docs say "Note that exclusion constraints are not supported with
> >> ON CONFLICT DO UPDATE."
> >>
> >> But I get the following error message
On 20 May 2015 at 17:54, Andres Freund wrote:
> On 2015-05-20 17:44:05 +0100, Thom Brown wrote:
>> On 8 May 2015 at 16:03, Andres Freund wrote:
>> > So I've committed the patch yesterday evening. I'm pretty sure there'll
>> > be some more minor things to change. But overall I feel good about the
On 05/20/2015 07:29 PM, CharSyam wrote:
Hi,
I changed typos error. and attached patch for this.
Thanks you.
I only changed comments only
Thanks, committed. Except for this one:
--- src/backend/utils/sort/logtape.c
+++ src/backend/utils/sort/logtape.c
@@ -926,7 +926,7 @@ LogicalTapeBackspace(
On 2015-05-20 17:44:05 +0100, Thom Brown wrote:
> On 8 May 2015 at 16:03, Andres Freund wrote:
> > So I've committed the patch yesterday evening. I'm pretty sure there'll
> > be some more minor things to change. But overall I feel good about the
> > current state.
> >
> > It'd be quite helpful if
Thanks :) You make sense.
2015-05-21 1:49 GMT+09:00 Heikki Linnakangas :
> On 05/20/2015 07:29 PM, CharSyam wrote:
>
>> Hi,
>>
>> I changed typos error. and attached patch for this.
>> Thanks you.
>>
>> I only changed comments only
>>
>
> Thanks, committed. Except for this one:
>
> --- src/backen
On Tue, May 19, 2015 at 5:34 PM, Bruno Harbulot
wrote:
> Users of question mark operators are already admitting their application and
> code isn't portable (since they are specific to PostgreSQL and its
> extensions). The problem has more to do with how the other tools around
> handle these custom
On 8 May 2015 at 16:03, Andres Freund wrote:
> So I've committed the patch yesterday evening. I'm pretty sure there'll
> be some more minor things to change. But overall I feel good about the
> current state.
>
> It'd be quite helpful if others could read the docs, specifically for
> insert, and c
1 - 100 of 133 matches
Mail list logo
