On Tue, May 19, 2015 at 04:55:11PM -0400, Robert Haas wrote:
> On Tue, May 19, 2015 at 1:35 PM, Andres Freund wrote:
> > I think part of that is saying "no" more efficiently, upfront. Which is
> > why I really want the triage step.
> > a) It's much better for the project to not have several "junio
On Tue, May 19, 2015 at 1:53 AM, Robert Haas wrote:
> On May 18, 2015, at 3:32 PM, Volker Aßmann
> wrote:
> > I know these measures won't protect against an experienced attacker who
> gains root access, but hope it slows them down sufficiently so the admins
> may have a chance to detect the atta
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 TABLE
CREATE INDEX idx ON test_ints(i);
CREATE INDEX
set enable_bitmapsca
Hi,
The attached patch fixes a typo in a comment in tablecmds.c.
Best regards,
Etsuro Fujita
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index 33ea387..5114e6f 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -2342,7 +234
On 19 May 2015 at 21:57, Simon Riggs wrote:
> It's not clear to me how a single INSERT could cause two or more UPDATEs.
>
CREATE TABLE mytable (
c1 int NOT NULL,
c2 int NOT NULL,
PRIMARY KEY (c1),
UNIQUE (c2)
);
INSERT INTO mytable (c1, c2) (10, 20);
INSERT INTO mytable (c1, c2) (
On Wed, May 20, 2015 at 2:40 AM, Jim Nasby wrote:
>
> On 5/19/15 9:19 PM, Fabrízio de Royes Mello wrote:
>>
>> We could add a second parameter to the current functions:
>> allow_own_pid DEFAULT false. To me that seems better than an
>> entirely separate set of functions.
>>
>>
>> +1 to
On 5/20/15 1:40 AM, Jim Nasby wrote:
> On 5/19/15 9:19 PM, Fabrízio de Royes Mello wrote:
>> We could add a second parameter to the current functions:
>> allow_own_pid DEFAULT false. To me that seems better than an
>> entirely separate set of functions.
>>
>>
>> +1 to add a second param
On 19 May 2015 at 19:18, Jan de Visser wrote:
> On May 19, 2015 09:31:32 PM Greg Sabino Mullane wrote:
> > Jan de Visser wrote:
> > >> Well, one could argue that it *is* their problem, as they should be
> using
> > >> the standard Postgres way for placeholders, which is $1, $2, $3...
> > >
> > >
Hi,
For the user created indexes in PostgreSQL 8.3.6, I would like to
know in which table (eg: pg_tablename) the index-tuple-count and
index-page-count meta-data statistics are stored.
Regards and Thanks,
Srinivas Karthik
On 20 May 2015 at 03:13, Noah Misch wrote:
> On Tue, May 19, 2015 at 04:55:11PM -0400, Robert Haas wrote:
> > On Tue, May 19, 2015 at 1:35 PM, Andres Freund
> wrote:
> > > I think part of that is saying "no" more efficiently, upfront. Which is
> > > why I really want the triage step.
> > > a) It
Hi, Hackers!
Attached is a patch against master to generalize the JSON-producing
functions in utils/adt/json.c and to provide a set of callbacks which can
be overridden the same way that is already provided for *parsing* JSON.
The motivation behind this to be able to produce specially-crafted JSO
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 seems a bit
> weird, but I think
While reading the commit- 5aa23504 for Replication Progress
Tracking, I came across few issues which I would like to share.
1. catalogs.sgml
+
+ local_lsn
+
pg_lsn
+
+ This node's LSN that at
+ which
remote_lsn has been replicated. Used to
+ flush commit records befo
On 05/20/2015 06:55 AM, Euler Taveira wrote:
Attached is a small typo.
Fixed, thanks.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscripti
On 05/20/2015 04:14 PM, Srinivas Karthik V wrote:
Hi,
For the user created indexes in PostgreSQL 8.3.6, I would like to
know in which table (eg: pg_tablename) the index-tuple-count and
index-page-count meta-data statistics are stored.
pg_class.reltuples and pg_class.relpages.
(I'm sure
On Wed, May 20, 2015 at 8:16 AM, Shulgin, Oleksandr
wrote:
> Hi, Hackers!
>
> Attached is a patch against master to generalize the JSON-producing
> functions in utils/adt/json.c and to provide a set of callbacks which can be
> overridden the same way that is already provided for *parsing* JSON.
>
David Steele writes:
> +1. I agree that cancelling/killing your own process should not be the
> default behavior.
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 applica
On Mon, Feb 2, 2015 at 8:57 PM, Andres Freund
wrote:
>
> Hi,
>
> I've, for a while, pondered whether we couldn't find a easier way than
> CSN to make snapshots cheaper as GetSnapshotData() very frequently is
> one of the top profile entries. Especially on bigger servers, where the
> pretty much gu
On Tue, May 19, 2015 at 10:31 PM, Greg Sabino Mullane
wrote:
>
> If you are running into situations
> where you have question mark operators in your queries, you have already
> lost
> the query abstraction battle. There will be no seamless switching if you
> are using jsonb, hstore, ltree, etc.
>
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
> session can never be reset, for ultra security, and one where the session
> can be reset, which allows secur
On Wed, May 20, 2015 at 4:20 AM, Volker Aßmann wrote:
> On Tue, May 19, 2015 at 1:53 AM, Robert Haas wrote:
>> On May 18, 2015, at 3:32 PM, Volker Aßmann
>> wrote:
>> > I know these measures won't protect against an experienced attacker who
>> > gains root access, but hope it slows them down suf
On 5/20/15 10:09 AM, Tom Lane wrote:
> David Steele writes:
>> +1. I agree that cancelling/killing your own process should not be the
>> default behavior.
>
> I think backwards compatibility probably trumps that argument. I have
> no objection to providing a different call that behaves this way
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
session can never be reset, for ultra security, and one where the session
On Tue, May 19, 2015 at 10:50 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Tue, May 19, 2015 at 2:34 PM, Bruno Harbulot <
> br...@distributedmatter.net> wrote:
>
>>
>> While I can imagine a Java PostgreSQL driver that would use the libpq
>> syntax, I can't see it being able to h
On Tue, May 19, 2015 at 9:51 PM, Dave Cramer wrote:
>
>
> Actually the issue is what to do about a number of connectors which use a
> fairly standard '?' as a placeholder.
> Notably absent from the discussion is ODBC upon which JDBC was modelled
> and probably predates any use of ? as an operator
On 05/20/2015 09:16 AM, Shulgin, Oleksandr wrote:
Hi, Hackers!
Attached is a patch against master to generalize the JSON-producing
functions in utils/adt/json.c and to provide a set of callbacks which
can be overridden the same way that is already provided for *parsing*
JSON.
The motivatio
On Tue, May 19, 2015 at 10:26 AM, Tom Lane wrote:
> To do it before every minor release would require re-indenting HEAD
> as well (since the whole point is to keep HEAD and the back branches
> consistent). I think we'd get too much push-back from developers
> whose pending patches got broken. We
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*
> higher barrier to acceptance. E
On Wed, May 20, 2015 at 8:29 AM, Bruno Harbulot wrote:
>
>
> On Tue, May 19, 2015 at 10:50 PM, David G. Johnston <
> david.g.johns...@gmail.com> wrote:
>
>> On Tue, May 19, 2015 at 2:34 PM, Bruno Harbulot <
>> br...@distributedmatter.net> wrote:
>>
>>>
>>> While I can imagine a Java PostgreSQL dr
On 05/19/2015 07:11 PM, Andrew Dunstan wrote:
On 05/18/2015 10:52 PM, Peter Geoghegan wrote:
On Mon, May 18, 2015 at 7:11 AM, Andrew Dunstan
wrote:
Here's an patch along those lines. It seems to do the trick, at
least for
your test case, and it has the merit of being very small, so small
I'
Hi,
I changed typos error. and attached patch for this.
Thanks you.
I only changed comments only
typos.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On May 20, 2015 6:43 AM, "David Steele" wrote:
>
> On 5/20/15 1:40 AM, Jim Nasby wrote:
> > On 5/19/15 9:19 PM, Fabrízio de Royes Mello wrote:
> >> We could add a second parameter to the current functions:
> >> allow_own_pid DEFAULT false. To me that seems better than an
> >> entirely
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
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
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 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
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 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 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
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
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
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
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
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
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
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
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
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
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,
* 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
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 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 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
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 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
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 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 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
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
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
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
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
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)
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
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
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 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
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: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
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 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
> "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
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
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
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
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
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
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 (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
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
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.
>
>
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
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 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
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
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
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 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
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
>>
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
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
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
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
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 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:
> 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 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
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 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
1 - 100 of 133 matches
Mail list logo
