On 05/05/2015 12:16 AM, Peter Geoghegan wrote:
On Sun, Apr 26, 2015 at 2:22 AM, Heikki Linnakangas hlinn...@iki.fi wrote:
The ability to specify a constraint by name hasn't been implemented, but
that would read quite naturally as:
INSERT INTO mytable ON CONFLICT ON CONSTRAINT my_constraint
On Tue, May 5, 2015 at 6:26 AM, David Rowley dgrowle...@gmail.com wrote:
On 5 May 2015 at 06:23, Robert Haas robertmh...@gmail.com wrote:
OK, committed and back-patched.
There's a couple of problems with this that the windows buildfarm members
are not happy with.
The attached patch seems
On Fri, May 1, 2015 at 1:06 PM, Andres Freund and...@anarazel.de wrote:
On 2015-05-01 13:03:39 -0400, Bruce Momjian wrote:
Applied and backpatched to 9.4.
Ah. Forgot about that. Thanks!
Andres
.oO(bugtracker?)
I don't really see how that would help. People can forget about a
ticket in a
Hello,
I am the one who suggested the patch to Credativ, so let me explain my
reasoning.
It is clear that it is basically impossible to get perfect security but
this patch would help to solve one small but for our use case quite
dangerous issue. Changing the password to something simple is
Hi,
Can someone look at this patch. It should fix bug #12845.
The current tests for conversions are very minimal. I expanded them a
bit for this bug.
I think the binary search in the .map files should be removed but I
leave that for another patch.
On Fri, May 1, 2015 at 1:16 PM, Stephen Frost sfr...@snowman.net wrote:
We really need to segregate the two.. By that what I mean is this: I
want an always-open bugfix CF, which allows us to keep track of
bugfix patches. Having something about applies to versions X, Y, Z
would be nice too...
v4, rebase (after pgbench moved to src) and use of the recently added
syntax_error function.
v5 which adds a forgotten header declaration for a new function, so as to
avoid a warning.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index
On Mon, May 4, 2015 at 5:21 AM, Petr Korobeinikov
pkorobeini...@gmail.com wrote:
I'm proposing to add two new subcommands in psql:
1. \ev viewname - edit view definition with external editor (like \ef for
function)
2. \sv viewname - show view definition (like \sf for function, for
On 05/05/2015 01:10 PM, Emre Hasegeli wrote:
I already replied his email [1]. Which issues do you mean?
Sorry, my bad please ignore the previous email.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Hi,
On 2015-05-06 00:42:14 +, Duran, Danilo wrote:
I am looking to better understand the thought behind a replication
slot's restart_lsn initialization. Currently in 9.4 and master, a
replication slot's restart_lsn is set to InvalidXLogRecPtr and will
only start tracking restart_lsn once
On 4/30/15 6:36 PM, Joe Wildish wrote:
I’m wondering if there are other people out there working on implementing SQL
ASSERTION functionality?
I was the last one, probably:
http://www.postgresql.org/message-id/1384486216.5008.17.ca...@vanquo.pezone.net.
I intend to pick up that work sometime,
On 5/3/15 2:27 PM, Tom Lane wrote:
1. Preventing undefined-symbol errors at link time might be standard
according to some platforms, but it is not the universal default, and
I think there is no very good reason to assume that it is possible
everywhere. So I'm afraid that prairiedog is just
On Fri, May 1, 2015 at 9:04 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Apr 30, 2015 at 11:05 PM, Sawada Masahiko sawada.m...@gmail.com
wrote:
VACUUM has both syntax: with parentheses and without parentheses.
I think we should have both syntax for REINDEX like VACUUM does
because it
On Tue, May 5, 2015 at 3:47 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, May 1, 2015 at 1:16 PM, Stephen Frost sfr...@snowman.net wrote:
We really need to segregate the two.. By that what I mean is this: I
want an always-open bugfix CF, which allows us to keep track of
bugfix
On Tue, May 5, 2015 at 8:40 AM, Andres Freund and...@anarazel.de wrote:
One additional thing I'm wondering about is the following: Right now
INSERT ... ON CONFLICT NOTHING does not acquire a row level lock on the
'target' tuple. Are we really ok with that? Because in this form ON
CONFLICT
In
http://www.postgresql.org/message-id/bn1pr04mb37467aa1d412223b3d4a595df...@bn1pr04mb374.namprd04.prod.outlook.com
it's revealed that the citext extension misdeclares its versions of
regexp_matches(): they should return SETOF text[] but they're marked
as returning just text[].
We know generally
On Sat, May 2, 2015 at 12:35 PM, Noah Misch n...@leadboat.com wrote:
Perhaps, rather than model it as master M waiting on worker list W1|W2|W3,
model it with queue-nonempty and queue-nonfull events, one pair per queue.
Each individual queue has only a single reader and a single writer.
In your
Tom Lane wrote:
* We can't use CREATE OR REPLACE FUNCTION in the upgrade script because
that intentionally doesn't let you change the result type of an existing
function. I considered doing a manual UPDATE of the pg_proc entry, but
then remembered why CREATE OR REPLACE FUNCTION is picky
I've read through all the error messages in the patch. Some comments:
postgres=# create table foo (id int4);
CREATE TABLE
postgres=# create unique index foo_y on foo (id) where id 0;
CREATE INDEX
postgres=# insert into foo values (-1) on conflict (id) where id 0 do
nothing;
ERROR:
On May 5, 2015, at 10:07 AM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
So AFAICS we need to actually drop and recreate
the citext regexp_matches() functions in the upgrade script. That means
ALTER EXTENSION citext UPDATE will fail if these functions are being
used in any views. That's
Alvaro Herrera alvhe...@2ndquadrant.com writes:
(I think it is possible that the behavior change is actually problematic
as opposed to just behaving differently. For instance, if the function
is used in a subselect that's expected to return only one row, and it
suddenly starts returning more,
David G. Johnston david.g.johns...@gmail.com writes:
On Tue, May 5, 2015 at 10:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
I think we should keep the 1.0 version this time, in back branches.
Agreed. Maybe we shouldn't even make 1.1 the default in
Hey folks,
Just had your standard... our pg_ tables are all bloated out, what is a
good way to take care of that. We have -s for reindexdb but not
vacuumdb. Thoughts?
JD
--
Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564
PostgreSQL Centered full stack support, consulting
On 5/4/15 8:37 PM, Stephen Frost wrote:
I don't follow this logic. The concerns raised above are about changing
our in-core logging. We haven't got in-core auditing and so I don't see
how they apply to it.
How is session auditing substantially different from statement logging?
I think it is
On 05/05/2015 03:06 PM, Joshua D. Drake wrote:
Hey folks,
Just had your standard... our pg_ tables are all bloated out, what is
a good way to take care of that. We have -s for reindexdb but not
vacuumdb. Thoughts?
What command will it run? VACUUM doesn't have a SYSTEM flag, unlike
On 05/05/2015 12:22 PM, Andrew Dunstan wrote:
On 05/05/2015 03:06 PM, Joshua D. Drake wrote:
Hey folks,
Just had your standard... our pg_ tables are all bloated out, what is
a good way to take care of that. We have -s for reindexdb but not
vacuumdb. Thoughts?
What command will it run?
On 5/1/15 10:55 AM, Euler Taveira wrote:
On 01-05-2015 11:14, Bruce Momjian wrote:
Currently initdb outputs suggested text on starting the server:
Success. You can now start the database server using:
/u/pgsql/bin/postgres -D /u/pgsql/data
or
Looking at patch 04, it seems to me that it would be better to have
the OpcInfo struct carry the typecache struct rather than the type OID,
so that we can avoid repeated typecache lookups in brin_deform_tuple;
something like
/* struct returned by OpcInfo amproc */
typedef struct BrinOpcInfo
{
Alvaro Herrera wrote:
Looking at patch 04, it seems to me that it would be better to have
the OpcInfo struct carry the typecache struct rather than the type OID,
so that we can avoid repeated typecache lookups in brin_deform_tuple;
Here's the patch.
--
Álvaro Herrera
On Mon, May 04, 2015 at 01:50:45PM -0400, Tom Lane wrote:
Sandro Santilli s...@keybit.net writes:
I'm comparing speed of some queries against tables having the same data
but different storage, and got an unexpected behavior.
The tables have 2 integer fields and a PcPatch field
(p,
On Tue, May 5, 2015 at 4:26 PM, Joshua D. Drake j...@commandprompt.com
wrote:
On 05/05/2015 12:22 PM, Andrew Dunstan wrote:
On 05/05/2015 03:06 PM, Joshua D. Drake wrote:
Hey folks,
Just had your standard... our pg_ tables are all bloated out, what is
a good way to take care of that.
On 2015-04-26 18:02:06 -0700, Peter Geoghegan wrote:
Remaining challenges
=
Another thing I'm wondering about is dealing with deferrable
constraints/deferred indexes.
a) Why does ExecCheckIndexConstraints() check for indisimmediate for
*all* indexes and not just when it's an
Hi,
On 2015-04-26 18:02:06 -0700, Peter Geoghegan wrote:
Remaining challenges
=
One additional thing I'm wondering about is the following: Right now
INSERT ... ON CONFLICT NOTHING does not acquire a row level lock on the
'target' tuple. Are we really ok with that? Because in
On Tue, May 5, 2015 at 8:05 AM, Volker Aßmann volker.assm...@gmail.com wrote:
Changing the password to something simple is immediately obvious as a
security flaw for most people who may come across database configurations,
but for the TRUST mode you actually need to know some background on why
On Tue, May 5, 2015 at 11:10 AM, Sawada Masahiko sawada.m...@gmail.com wrote:
On Fri, May 1, 2015 at 9:04 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Apr 30, 2015 at 11:05 PM, Sawada Masahiko sawada.m...@gmail.com
wrote:
VACUUM has both syntax: with parentheses and without
On 2015-05-04 14:16:42 -0700, Peter Geoghegan wrote:
On Sun, Apr 26, 2015 at 2:22 AM, Heikki Linnakangas hlinn...@iki.fi wrote:
The ability to specify a constraint by name hasn't been implemented, but
that would read quite naturally as:
INSERT INTO mytable ON CONFLICT ON CONSTRAINT
On Tue, May 5, 2015 at 10:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
(I think it is possible that the behavior change is actually problematic
as opposed to just behaving differently. For instance, if the function
is used in a subselect that's
After looking at 05 again, I don't like the same as % business.
Creating a whole new class of exceptions is not my thing, particularly
not in a regression test whose sole purpose is to look for exceptional
(a.k.a. wrong) cases. I would much rather define the opclasses for
those two datatypes
On 05/05/2015 11:57 AM, Emre Hasegeli wrote:
From my point of view as a reviewer this patch set is very close to being
committable.
Thank you. The new versions are attached.
Nice, I think it is ready now other than the issues Alvaro raised in his
review[1]. Have you given those any
On 05/05/2015 04:24 AM, Alvaro Herrera wrote:
Stefan Keller wrote:
I'm keen to see if a PostGIS specialist jumps in and adds PostGIS
geometry support.
Did you test the patch proposed here already? It could be a very good
contribution.
Indeed, I have done some testing of the patch but more
Indeed, I have done some testing of the patch but more people testing would
be nice.
The inclusion opclass should work for other data types as long
required operators and SQL level support functions are supplied.
Maybe it would work for PostGIS, too.
--
Sent via pgsql-hackers mailing list
On 5 May 2015 at 06:23, Robert Haas robertmh...@gmail.com wrote:
OK, committed and back-patched.
There's a couple of problems with this that the windows buildfarm members
are not happy with.
The attached patch seems to work locally.
Regards
David Rowley
fsync_win32_fix.patch
Description:
Can you please explain what is the purpose of patch 07? I'm not sure I
understand; are we trying to avoid having to add pg_amproc entries for
these operators and instead piggy-back on btree opclass definitions?
Not too much in love with that idea; I see that there is less tedium in
that the brin
On Tue, May 5, 2015 at 9:36 AM, Andres Freund and...@anarazel.de wrote:
Theoretically this changes the pictures for FDWs, right? Right now
there's
+para
+ commandINSERT/ with an literalON CONFLICT/ clause is not
+ supported with a unique index inference specification, since a
+
Nice, I think it is ready now other than the issues Alvaro raised in his
review[1]. Have you given those any thought?
I already replied his email [1]. Which issues do you mean?
[1]
http://www.postgresql.org/message-id/CAE2gYzxQ-Gk3q3jYWT=1enlebsgcgu28+1axml4omcwjbkp...@mail.gmail.com
--
45 matches
Mail list logo
