On 27 September 2014 23:23, Peter Geoghegan p...@heroku.com wrote:
On Thu, Sep 25, 2014 at 1:48 PM, Simon Riggs si...@2ndquadrant.com wrote:
I hate the fact
that you have written no user facing documentation for this feature.
Attached patch adds a commit to the existing patchset. For the
On Sat, Sep 27, 2014 at 11:21 PM, Simon Riggs si...@2ndquadrant.com wrote:
My request was for the following...
Agree command semantics by producing these things
* Explanatory documentation (Ch6.4 Data Manipulation - Upsert)
Do you really think I could get an entire chapter out of this?
*
Hi.
I'm a core developer on npgsql (the Postgresql .NET provider), we're hard
at work on a major 3.0 version. I have a fundamental question that's been
bugging me for a while and would like to get your opinion on it.
Npgsql currently supports three basic query modes: simple, client-side
On 9/28/14, 11:53 AM, Shay Rojansky wrote:
I would, in theory, love to switch the entire thing to binary and thereby
avoid all textual parsing once and for all. If I understand correctly, this
means all queries must be implemented as extended queries, with numerous
extra client-server roundtrips
On 09/28/2014 09:40 AM, Peter Geoghegan wrote:
No explanation of why the CONFLICTING() syntax differs from OLD./NEW.
syntax used in triggers
Why should it be the same?
Both can be seen as cases where you refer to a field of a tuple, which
is usually done with FOO.bar.
--
Andreas Karlsson
On 09/28/2014 03:40 PM, Peter Geoghegan wrote:
Do you really think I could get an entire chapter out of this?
Yes. It might be a short chapter, but once you extract the existing
upsert example from the docs and how why the naïve approach doesn't work
there'll be enough to go on.
People get this
On 2014-09-28 17:32:21 +1300, David Rowley wrote:
My understanding of foreign keys is that any pending foreign key triggers
will be executed just before the query completes, so we should only ever
encounter pending foreign key triggers during planning when we're planning
a query that's being
Marko Tiikkaja ma...@joh.to writes:
On 9/28/14, 11:53 AM, Shay Rojansky wrote:
[ complaint about multiple round trips in extended protocol ]
You don't have to do multiple round-trips for that; you can just send
all the messages in one go. See how e.g. libpq does it in PQexecParams().
David Rowley dgrowle...@gmail.com writes:
Please correct anything that sounds wrong here, but my understanding is
that we'll always plan a query right before we execute it, with the
exception of PREPARE statements where PostgreSQL will cache the query plan
when the prepare statement is first
Thanks guys, that makes perfect sense to me...
Am Sonntag, 28. September 2014 schrieb Tom Lane :
Marko Tiikkaja ma...@joh.to javascript:; writes:
On 9/28/14, 11:53 AM, Shay Rojansky wrote:
[ complaint about multiple round trips in extended protocol ]
You don't have to do multiple
Hi,
I have created a small patch to postgres source (in particular the
psql part of it) that modifies the way time spent executing the SQL
commands is printed out.
The idea is to have a human readable time printed, e.g.:
Time: 1:32:15.45 m:s:ms
Time: 2_10:12:55:444.033 d_h:m:s:ms
Attached you
Hi,
I have created a small patch to postgres source (in particular the
psql part of it) that modifies the way tab expansion is handled.
The idea is to be able to toggle tab expansion, having the default set
to ON (as it is now). If turned off, tab characters on command line in
interactive mode
Bogdan Pilch bog...@matfyz.cz writes:
The idea is to be able to toggle tab expansion, having the default set
to ON (as it is now). If turned off, tab characters on command line in
interactive mode are not evaluated nor expanded, but just copied.
You can already suppress tab expansion with the
On 27 September 2014 09:29, Andres Freund and...@anarazel.de wrote:
On 2014-09-27 10:23:33 +0300, Heikki Linnakangas wrote:
This patch has gotten a fair amount of review, and has been rewritten once
during the commitfest. I think it's pretty close to being committable, the
only remaining
On 28 September 2014 08:40, Peter Geoghegan p...@heroku.com wrote:
On Sat, Sep 27, 2014 at 11:21 PM, Simon Riggs si...@2ndquadrant.com wrote:
My request was for the following...
Agree command semantics by producing these things
* Explanatory documentation (Ch6.4 Data Manipulation - Upsert)
On Sun, Sep 28, 2014 at 1:17 PM, Simon Riggs si...@2ndquadrant.com wrote:
MERGE INTO tab USING VALUES ('foo')
WHEN NOT MATCHED THEN
INSERT (colB)
WHEN MATCHED THEN
UPDATE SET colB = NEW.p1
and throwing ERROR: full syntax for MERGE not implemented yet if
people stretch too far.
That
On Sun, Sep 28, 2014 at 1:31 PM, Peter Geoghegan p...@heroku.com wrote:
There was informal meeting of this at the dev meeting a in 2012.
I mean: There was informal agreement that as long as we're working on
a feature that makes useful, UPSERT-like guarantees, we shouldn't use
the MERGE syntax.
On 29/09/14 00:49, Bogdan Pilch wrote:
Hi,
I have created a small patch to postgres source (in particular the
psql part of it) that modifies the way time spent executing the SQL
commands is printed out.
The idea is to have a human readable time printed, e.g.:
Time: 1:32:15.45 m:s:ms
Time:
On 29/09/14 09:31, Peter Geoghegan wrote:
On Sun, Sep 28, 2014 at 1:17 PM, Simon Riggs si...@2ndquadrant.com wrote:
MERGE INTO tab USING VALUES ('foo')
WHEN NOT MATCHED THEN
INSERT (colB)
WHEN MATCHED THEN
UPDATE SET colB = NEW.p1
and throwing ERROR: full syntax for MERGE not implemented
On Sun, Sep 28, 2014 at 3:41 PM, Gavin Flower
gavinflo...@archidevsys.co.nz wrote:
How about have a stub page for MERGE, saying it is not implemented yet, but
how about considering UPSERT - or something of that nature?
I can suspect that people are much more likely to look for 'MERGE' in an
On 9/28/14, 7:49 AM, Bogdan Pilch wrote:
I have created a small patch to postgres source (in particular the
psql part of it) that modifies the way time spent executing the SQL
commands is printed out.
The idea is to have a human readable time printed
There are already a wide range of human
On Sun, Sep 28, 2014 at 1:36 AM, Michael Paquier michael.paqu...@gmail.com
wrote:
Hi all,
Recent commit 491c029 introducing RLS has broken a bit the verbose logs
of pg_dump, one message missing a newline:
+ if (g_verbose)
+ write_msg(NULL, reading
On 29/09/14 11:57, Peter Geoghegan wrote:
On Sun, Sep 28, 2014 at 3:41 PM, Gavin Flower
gavinflo...@archidevsys.co.nz wrote:
How about have a stub page for MERGE, saying it is not implemented yet, but
how about considering UPSERT - or something of that nature?
I can suspect that people are
On Sun, Sep 28, 2014 at 6:15 PM, Gavin Flower
gavinflo...@archidevsys.co.nz wrote:
What I have a problem with is using the MERGE syntax to match people's
preexisting confused ideas about what MERGE does. If we do that, it'll
definitely bite us when we go to make what we'd be calling MERGE do
On Mon, Sep 29, 2014 at 10:07 AM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
The schema name is missing... attached patch add it.
Ah, right, thanks. It didn't occur to me immediately :) Your patch looks
good to me, and you are updating as well the second message that missed the
On 29/09/14 14:20, Peter Geoghegan wrote:
On Sun, Sep 28, 2014 at 6:15 PM, Gavin Flower
gavinflo...@archidevsys.co.nz wrote:
What I have a problem with is using the MERGE syntax to match people's
preexisting confused ideas about what MERGE does. If we do that, it'll
definitely bite us when we
On Fri, Sep 26, 2014 at 10:49:42AM +0400, Alexander Korotkov wrote:
Does this also fix the identical PostGIS problem or is there something
PostGIS needs to do?
This patch provides general infrastructure for recheck in KNN-GiST. PostGIS
need corresponding change in its GiST opclass.
On Tue, Sep 16, 2014 at 06:56:24PM +0400, Alexander Korotkov wrote:
On Tue, Sep 16, 2014 at 12:14 PM, Emre Hasegeli e...@hasegeli.com wrote:
Changing the default opclasses should work if we make
pg_dump --binary-upgrade dump the default opclasses with indexes
and exclusion
On Mon, Sep 15, 2014 at 03:42:20PM -0700, Peter Geoghegan wrote:
On Mon, Sep 15, 2014 at 12:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
No. And we don't know how to change the default opclass without
breaking things, either.
Is there a page on the Wiki along the lines of things that we
On 09/26/2014 06:20 PM, Josh Berkus wrote:
Overall, I'm satisfied with the performance of the length-and-offset
patch.
Oh, also ... no bugs found.
So, can we get Beta3 out now?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list
Josh Berkus j...@agliodbs.com writes:
So, can we get Beta3 out now?
If nobody else steps up and says they want to do some performance
testing, I'll push the latest lengths+offsets patch tomorrow.
Are any of the other open items listed at
Hi,
I am newbie in postgresql development, so i took easy item in Todo list
Add generate_series(numeric, numeric). First, i changed function with
analogue funcionality (generate_series_timestamp) and added new object in
pg_proc (object id is 6000). My changes successfully was compiled.
I have
On 09/29/2014 06:41 AM, Gavin Flower wrote:
I can suspect that people are much more likely to look for 'MERGE' in an
index, or look for 'MERGE' in the list of SQL commands, than 'UPSERT'.
and/or to be looking for MySQL's:
ON DUPLICATE KEY {IGNORE|UPDATE}
What astonishes me when I look
On Sun, Sep 28, 2014 at 8:53 PM, Craig Ringer cr...@2ndquadrant.com wrote:
there's an alarming lack of concern for concurrency, just a couple of
links to :
http://www.mssqltips.com/sqlservertip/3074/use-caution-with-sql-servers-merge-statement/
(BTW, that article contains some useful
On 09/29/2014 12:03 PM, Peter Geoghegan wrote:
On Sun, Sep 28, 2014 at 8:53 PM, Craig Ringer cr...@2ndquadrant.com wrote:
there's an alarming lack of concern for concurrency, just a couple of
links to :
http://www.mssqltips.com/sqlservertip/3074/use-caution-with-sql-servers-merge-statement/
On 2014-09-28 20:32:30 -0400, Gregory Smith wrote:
On 9/28/14, 7:49 AM, Bogdan Pilch wrote:
I have created a small patch to postgres source (in particular the
psql part of it) that modifies the way time spent executing the SQL
commands is printed out.
The idea is to have a human readable
Andres Freund and...@2ndquadrant.com writes:
On 2014-09-28 20:32:30 -0400, Gregory Smith wrote:
On 9/28/14, 7:49 AM, Bogdan Pilch wrote:
I have created a small patch to postgres source (in particular the
psql part of it) that modifies the way time spent executing the SQL
commands is printed
37 matches
Mail list logo
