Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom I spent a fair amount of time cleaning this patch up to get it
Tom into committable shape, but as I was working on the documentation
Tom I started to lose enthusiasm for it, because I was having a hard
Tom time coming up with compelling
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Now this I think is wrong; I think it's just as robust against
schema changes as using the composite value directly would
be. Consider the case where foo and reference_foo match with the
exception of dropped columns; the code as it is should
Andrew Gierth wrote:
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom Right, but we should be trying to move in that direction. I see
Tom your point though that (*) is more notationally consistent with
Tom that case. Maybe we should be looking at trying to implement T641
Tom in full and
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Andrew Gierth wrote:
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom Right, but we should be trying to move in that direction. I see
Tom your point though that (*) is more notationally consistent with
Tom that case. Maybe we should be looking
On 4/8/15 7:04 AM, Fujii Masao wrote:
I'm thinking to apply the attached patch.
But does anyone want to keep supporting the option? Why?
Nuke it.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing
Tom == Tom Lane t...@sss.pgh.pa.us writes:
One example that comes up occasionally (and that I've had to do
myself more than once) is this: given a table foo and another with
identical schema reference_foo, apply appropriate inserts, updates
and deletes to table foo to make the content of
Andrew Gierth and...@tao11.riddles.org.uk writes:
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom I spent a fair amount of time cleaning this patch up to get it
Tom into committable shape, but as I was working on the documentation
Tom I started to lose enthusiasm for it, because I was having
On Tue, Feb 24, 2015 at 5:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Also, it strikes me that we could significantly reduce, maybe even fully
eliminate, the funny behaviors around the existing base_yylex()
substitutions if we made them use the same idea, ie replace the leading
token with
Greg Stark st...@mit.edu writes:
On Tue, Feb 24, 2015 at 5:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Also, it strikes me that we could significantly reduce, maybe even fully
eliminate, the funny behaviors around the existing base_yylex()
substitutions if we made them use the same idea, ie
On Tue, Apr 7, 2015 at 10:59 PM, Peter Geoghegan p...@heroku.com wrote:
The documentation has been updated to reflect all of this.
By the way, for the convenience of reviewers I continue to maintain a
mirror of pre-built documentation as outlined here:
On 8 April 2015 at 16:27, Stephen Frost sfr...@snowman.net wrote:
2). In prepend_row_security_policies(), I think it is better to have
any table RLS policies applied before any hook policies, so that a
hook cannot be used to bypass built-in RLS.
While I agree that we want to include the RLS
Qingqing Zhou zhouqq.postg...@gmail.com writes:
Not sure if I understand correctly: in uniqueness check, we see all
possible tuples with a dirty snapshot. For a tuple version inserted
and updated by myself, it is surely dead no matter how the transaction
ends. So I interpret that we can
Hi all,
I noticed two things while looking at the SSL test suite:
1) When running the tests, some logs are generated in client-log, but
this log file has no entry in .gitignore... A patch is attached.
2) cp is used with a wildcard and system_or_bail in ServerSetup.pm:
system_or_bail cp
On Wed, Apr 8, 2015 at 1:09 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Apr 8, 2015 at 1:57 AM, Sawada Masahiko sawada.m...@gmail.com wrote:
On Wed, Apr 8, 2015 at 1:11 AM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
On Tue, Apr 7, 2015 at 1:04 PM, Sawada Masahiko
Dean Rasheed dean.a.rash...@gmail.com wrote:
Re-using the SQLSTATE 44000 is a bit iffy too. We should
probably define something to differentiate this, like:
44P01 ROW SECURITY WRITE POLICY VIOLATION
Yes, that sounds sensible.
I would be more inclined to use:
42501
* Kevin Grittner (kgri...@ymail.com) wrote:
Dean Rasheed dean.a.rash...@gmail.com wrote:
Re-using the SQLSTATE 44000 is a bit iffy too. We should
probably define something to differentiate this, like:
44P01 ROW SECURITY WRITE POLICY VIOLATION
Yes, that sounds sensible.
I would
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
On 7 April 2015 at 16:21, Stephen Frost sfr...@snowman.net wrote:
Agreed and we actually have a patch from Dean already to address this,
it's just been waiting on me (with a couple of other ones). It'd
certainly be great if you have
On Fri, Apr 3, 2015 at 08:32:08PM -0400, Noah Misch wrote:
On Thu, Apr 02, 2015 at 07:31:52AM -0400, Bruce Momjian wrote:
On Thu, Apr 2, 2015 at 01:44:59AM -0400, Noah Misch wrote:
On Wed, Apr 01, 2015 at 10:49:01PM -0400, Bruce Momjian wrote:
On Sat, Jan 10, 2015 at 02:53:13PM -0500,
Pushed this.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Andrew Gierth and...@tao11.riddles.org.uk writes:
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom and not at all robust against schema changes (the same problem as
Tom with the patch's approach to UPDATE).
Now this I think is wrong; I think it's just as robust against schema
changes as
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
conflicts. I think at this point it's easiest if I just take it from
here.
I'm puzzled about the
On Wed, Apr 8, 2015 at 4:57 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Apr 7, 2015 at 3:35 PM, Peter Eisentraut pete...@gmx.net wrote:
On 4/7/15 3:33 PM, Tom Lane wrote:
I tried to mark the UPDATE SET (*) patch as returned with feedback,
but the CF app informed me that if I did
On 4/7/15 4:32 PM, Alvaro Herrera wrote:
Executive summary:
There is now a CommandDeparse_hook;
deparse_utility_command is provided as an extension, intended for 9.6;
rest of patch would be pushed to 9.5.
Long version:
I've made command deparsing hookable. Attached there are three
On Mon, Apr 6, 2015 at 11:02 AM, Petr Jelinek p...@2ndquadrant.com wrote:
On 06/04/15 14:30, Petr Jelinek wrote:
On 06/04/15 11:02, Simon Riggs wrote:
Are we ready for a final detailed review and commit?
I plan to send v12 in the evening with some additional changes that came
up from
On April 8, 2015 9:28:50 PM GMT+02:00, Magnus Hagander mag...@hagander.net
wrote:
On Wed, Apr 8, 2015 at 4:57 AM, Robert Haas robertmh...@gmail.com
wrote:
On Tue, Apr 7, 2015 at 3:35 PM, Peter Eisentraut pete...@gmx.net
wrote:
On 4/7/15 3:33 PM, Tom Lane wrote:
I tried to mark the UPDATE
On 04/08/2015 03:28 PM, Magnus Hagander wrote:
On Wed, Apr 8, 2015 at 4:57 AM, Robert Haas robertmh...@gmail.com
mailto:robertmh...@gmail.com wrote:
On Tue, Apr 7, 2015 at 3:35 PM, Peter Eisentraut pete...@gmx.net
mailto:pete...@gmx.net wrote:
On 4/7/15 3:33 PM, Tom Lane wrote:
On 2015/04/08 7:44, Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
To support ROW_MARK_REFERENCE on (postgres_fdw) foreign tables, I'd like
to propose the following FDW APIs:
RowMarkType
GetForeignRowMarkType(Oid relid,
LockClauseStrength
On Wed, Apr 8, 2015 at 11:48:11AM -0400, Donald Stufft wrote:
Currently replacing the SSL certificates for PostgreSQL requires a full server
restart. However in the infrastructure for www.python.org (and in the future,
pypi.python.org as well) we use short lived certificates (1 day) that
2015-04-09 3:45 GMT+09:00 Alvaro Herrera alvhe...@2ndquadrant.com:
Pushed this.
Thanks!
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Apr 8, 2015 at 10:53 PM, Sawada Masahiko sawada.m...@gmail.com wrote:
On Wed, Apr 8, 2015 at 1:09 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Apr 8, 2015 at 1:57 AM, Sawada Masahiko sawada.m...@gmail.com
wrote:
On Wed, Apr 8, 2015 at 1:11 AM, Fabrízio de Royes Mello
On Thu, Apr 9, 2015 at 12:33 AM, Jim Nasby jim.na...@bluetreble.com wrote:
On 4/8/15 7:04 AM, Fujii Masao wrote:
I'm thinking to apply the attached patch.
But does anyone want to keep supporting the option? Why?
Nuke it.
There seem no objections, so just pushed.
Regards,
--
Fujii Masao
On Apr 9, 2015, at 1:08 AM, Andres Freund and...@anarazel.de wrote:
I'm not convinced we really need a version that closes and moves a entry. But
if we indeed want it we can just name it moved.
+1.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Tue, Apr 7, 2015 at 12:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I tried to mark the UPDATE SET (*) patch as returned with feedback,
but the CF app informed me that if I did that the patch would
automatically be moved to the next commitfest. That seems completely
stupid. There is no need
Hanada-san,
In addition to your comments, I removed useless code that retrieves
ForeignPath
from outer/inner RelOptInfo and store them into ForeignPath#fdw_private. Now
postgres_fdw’s join pushd-down is free from existence of ForeignPath under the
join relation. This means that we can
On Thu, Apr 9, 2015 at 9:20 AM, Robert Haas robertmh...@gmail.com wrote:
On Apr 9, 2015, at 1:08 AM, Andres Freund and...@anarazel.de wrote:
I'm not convinced we really need a version that closes and moves a entry.
But if we indeed want it we can just name it moved.
+1.
+1. Sounds like a
Currently replacing the SSL certificates for PostgreSQL requires a full server
restart. However in the infrastructure for www.python.org (and in the future,
pypi.python.org as well) we use short lived certificates (1 day) that
automatically get rotated when 75% of their lifetime is used up. This
36 matches
Mail list logo
