On Mon, May 4, 2015 at 9:00 PM, Andres Freund wrote:
> I think it's pretty clear that we'll have to require that.
Okay, then. I'll push out revised testing of column-level privileges
later. (Andres rebased, and we're now pushing code to:
https://github.com/petergeoghegan/postgres/commits/insert_c
On 2015-05-04 19:13:27 -0700, Peter Geoghegan wrote:
> A question has come up about RTEs, column-level privileges and BEFORE
> triggers. This commit message gives a summary:
>
> https://github.com/petergeoghegan/postgres/commit/87b9f27055e81d1396db3d10a5e9d01c52603783
>
> I'm pretty sure that I'l
Stefan Keller wrote:
> Hi,
>
> 2015-05-05 2:51 GMT+02:00 Andreas Karlsson :
> > From my point of view as a reviewer this patch set is very close to being
> > committable.
>
> I'd like to thank already now to all committers and reviewers and hope
> BRIN makes it into PG 9.5.
> As a database instru
On Fri, May 1, 2015 at 7:49 AM, Andres Freund wrote:
>> seems weird for both the BEFORE INSERT and BEFORE UPDATE triggers to
>> get a crack at the same tuple, so your way might be better after all.
>> But on the other hand, the BEFORE INSERT trigger might have had side
>> effects, so we can't just
Hi,
2015-05-05 2:51 GMT+02:00 Andreas Karlsson :
> From my point of view as a reviewer this patch set is very close to being
> committable.
I'd like to thank already now to all committers and reviewers and hope
BRIN makes it into PG 9.5.
As a database instructor, conference organisator and geospa
From my point of view as a reviewer this patch set is very close to
being committable.
= brin-inclusion-v06-01-sql-level-support-functions.patch
This patch looks good.
= brin-inclusion-v06-02-strategy-numbers.patch
This patch looks good, but shouldn't it be merged with 07?
= brin-inclusion-v
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 5/4/15 3:00 PM, Stephen Frost wrote:
> > One particular advantage of having the extension is that having it
> > doesn't impact existing users of the in-core logging system. I don't
> > recall any specific proposals for improving the in-core logging
On 5/4/15 3:00 PM, Stephen Frost wrote:
> One particular advantage of having the extension is that having it
> doesn't impact existing users of the in-core logging system. I don't
> recall any specific proposals for improving the in-core logging system
> to add the capabilities for session logging
Did this every go any further?
I wrote some data transformation script at work, and after seeing "with
count -2017657667" (and similar) in my scripts log I got a bit worried.
seeing else where were folks just run a full on count(*) later to check
counts but that is even MORE time and I was think
On Wed, Apr 29, 2015 at 12:09 PM, Robert Haas wrote:
>> * Don't change the names of the pseudo-alias EXCLUDED.* (or the alias
>> TARGET.*). Those seem fine to me as well.
>
> There seem to be a few votes for NEW and OLD. That's what I proposed
> originally, and (surprise, surprise) I still like t
Folks,
We are now three tzdata changes behind. There are bugs in pg_dump
which create real restore errors for people using PostGIS, one of our
most popular extensions.
Can we please wrap and ship 9.4.2, etc., and do it soon?
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235
In 6 weeks, people start arriving in Ottawa for PGCon 2015. Have you
registered? There's still time. Get in today.
We have a great list of talks: http://www.pgcon.org/2015/schedule/events.en.html
Given by great speakers: http://www.pgcon.org/2015/schedule/speakers.en.html
You'll want to be ther
On Sun, Apr 26, 2015 at 2:22 AM, Heikki Linnakangas 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 UPDATE ...
For the record, I have made this change on Github
On 5/1/15 12:33 PM, Andres Freund wrote:
> On 2015-04-08 19:19:29 +0100, Greg Stark wrote:
>> I'm not sure what the best way to handle the hand-off from patch
>> contribution to reviewer/committer. If I start tweaking things then
>> you send in a new version it's actually more work to resolve the
>
On Fri, May 1, 2015 at 1:05 PM, Qingqing Zhou wrote:
> On Thu, Apr 30, 2015 at 5:04 PM, Tom Lane wrote:
>>
>> I think I'd have done many of these as
>>
>> + PlanState *outerPlan = outerPlanState(node);
>>
>> rather than finding assorted random places to initialize the variables.
>>
>
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 4/30/15 6:05 AM, Fujii Masao wrote:
> > The specification of "session audit logging" seems to be still unclear to
> > me.
>
> As I had mentioned previously, I would prefer session audit logging to
> be integrated with the normal statement logging c
Here's a cleaned up version of this patch; I threw together a very quick
test module, and updated a conflicting OID. As far as I can tell, I'm
only missing the documentation updates before this is push-able.
One change to note is that the AlterTable support used to ignore
commands that didn't mat
On Fri, May 1, 2015 at 10:41 AM, Abhijit Menon-Sen wrote:
> At 2015-05-01 09:57:28 -0400, robertmh...@gmail.com wrote:
>>
>> If you don't object to this version, I'll commit it.
>
> Looks fine to me, thank you.
OK, committed and back-patched.
> As for the non-backpatchable 0002, I agree with And
On 05/04/2015 07:04 PM, Zhang Zq wrote:
hi,
I found the code in 'backend/access/transam/xloginsert.c' as that:
XLogRecordAssemble:
if (prev_regbuf && RelFileNodeEquals(regbuf->rnode, prev_regbuf->rnode))
{
samerel = true;
bkpb.fork_flags |= BKPBLOCK_SAME_R
Sandro Santilli 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", custom type from pgPointCloud).
> There are no TOASTs involved (the toast tab
On Mon, May 4, 2015 at 6:26 AM, Pavel Stehule
wrote:
>
>
> 2015-05-04 11:21 GMT+02:00 Petr Korobeinikov :
>
>> Hackers!
>>
>> 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
About view.
I found where I saw it was a discussion solve some problems with view
https://wiki.postgresql.org/wiki/Todo#Views_and_Rules, ie it is in the list
of TODO, so there is a chance that it will be implemented.
03 Май 2015 г. 12:15 пользователь "Sergey Grinko"
написал:
> Thank you Jim!
> Vi
On Tue, May 5, 2015 at 1:04 AM, Zhang Zq wrote:
> There is the only place that prev_regbuf is assigned, so prev_regbuf will
> never be assigned.
> The patch will fix it, Thanks.
Indeed. I think you are right. We never set prev_regbuf with the current code.
--
Michael
--
Sent via pgsql-hackers
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", custom type from pgPointCloud).
There are no TOASTs involved (the toast table associated with the table
with M
hi,
I found the code in 'backend/access/transam/xloginsert.c' as that:
XLogRecordAssemble:
if (prev_regbuf && RelFileNodeEquals(regbuf->rnode, prev_regbuf->rnode))
{
samerel = true;
bkpb.fork_flags |= BKPBLOCK_SAME_REL;
prev_regbuf = regbuf;
}
On Fri, May 1, 2015 at 12:29 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, May 1, 2015 at 9:09 AM, Marko Tiikkaja wrote:
>>> We recently hit a similar case in our production environment. What was
>>> annoying about it is that there didn't seem to be a way for the application
>>> to fix t
On 04/30/2015 08:36 AM, Pavel Stehule wrote:
Still issue is not fixed still
create type pt as (a int, b int);
postgres=# select json_populate_record('(10,20)'::pt, '{}');
WARNING: TupleDesc reference leak: TupleDesc 0x7f413ca325b0
(16560,-1) still referenced
Looking at it now. (Please re
Hello,
>Well, speaking of the two-arg form vs alternate name, here's a version of
the patch which includes the >new behavior
Thought i will attempt a review.
The patch applies cleanly to latest HEAD.
patch -p1 <
/home/Sameer/Downloads/0001-Add-two-arg-form-of-current_setting-to-optionally-su.pat
2015-05-04 11:21 GMT+02:00 Petr Korobeinikov :
> Hackers!
>
> 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
> consistency)
>
+1
Pavel
> On 04 May 2015, at 06:20, Dmitry Shirokov wrote:
>
> Hi all,
>
> Are there any plans to introduce in next versions of Postgres a schema
> validation for JSON field type? It would be very nice to have a support of
> something like json-schema spec, see
> http://json-schema.org/documentation
--On 1. Mai 2015 11:30:51 -0700 Tom Lane wrote:
> No. The non-parameterized paths for a given relation must all have the
> same rowcount estimates; otherwise the path comparison logic fails
> fundamentally. Another way to look at it is that every correct path
> will yield the same number of r
Hackers!
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
consistency)
What's inside:
1. review-ready implementation of \ev and \sv psql subcomma
--On 30. April 2015 08:00:23 -0400 Robert Haas
wrote:
> But... the user could use password authentication with the password
> set to "x" and that would be insecure, too, yet not prevented by any
> of this. I think it's pretty hard to prevent someone who has
> filesystem-level access to the dat
33 matches
Mail list logo
