* auto_explain.tgz
A contrib module version of auto-explain.
An arguable part is initializing instruments in ExecutorRun_hook.
The initialization should be done in ExecutorStart normally, but
it is too late in the hook. Is it safe? or are there any better idea?
README is a plain-text for
Peter Eisentraut wrote:
It was pointed out to me today that a zero-dimensional
matrix is a scalar. This makes a bit of sense, if you say
that
'{{56}}' is of type int[][], 2 dimensions
'{56}' is of type int[], 1 dimension
'56' is of type int, 0 dimensions
Notice that the number of brace
With CVS HEAD, I'm getting the following error when I try to access a
system column from within trigger (which I'm doing just for debug
purposes):
create table foo (a int);
create or replace function foo_trig_fn() returns trigger as $$
begin
raise notice 'In trigger: added %', new.ctid;
2009/12/4 Dean Rasheed dean.a.rash...@googlemail.com:
With CVS HEAD...
create table foo (a int);
create or replace function foo_trig_fn() returns trigger as $$
begin
raise notice 'In trigger: added %', new.ctid;
return new;
end
$$ language plpgsql;
create trigger foo_trig after
2010/1/9 Tom Lane t...@sss.pgh.pa.us:
Dean Rasheed dean.a.rash...@googlemail.com writes:
ERROR: attribute number -1 exceeds number of columns 1
I guess your previous message slipped through the cracks --- sorry about
that. It looks like the best fix is to teach ExecEvalFieldSelect
2010/1/9 Tom Lane t...@sss.pgh.pa.us:
OK, I admit that I'm totally new that area of code, so I'm not seeing
it - what does it break?
The main problem is...
Ah OK. Thanks for the explanation.
I think that a variant of your idea could be made to work: change
plpgsql_LookupIdentifiers to a
2010/1/9 Tom Lane t...@sss.pgh.pa.us:
Dean Rasheed dean.a.rash...@googlemail.com writes:
I wonder if it might be better to have plpgsql_parse_dblword() ignore
plpgsql_LookupIdentifiers, and always do the lookups.
Not if you'd like things to still work.
OK, I admit that I'm totally new
2010/1/10 Tom Lane t...@sss.pgh.pa.us:
I've applied a patch along these lines.
Cool. Thanks, that works great.
Cheers,
Dean
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2010/1/17 Tom Lane t...@sss.pgh.pa.us:
I want to do something about the open item discussed in this thread:
http://archives.postgresql.org/message-id/2009081446.ga25...@depesz.com
The right way to handle that, IMO, is to create pg_constraint rows for
triggers created via CREATE CONSTRAINT
2010/1/18 Tom Lane t...@sss.pgh.pa.us:
Dean Rasheed dean.a.rash...@googlemail.com writes:
Agreed. That's much neater. However, it does introduce a change in
behaviour - if you have 2 constraints with the same name in different
schemas, one deferrable, and one not, and the non-deferrable one
Oops, my fault. The list returned by ExecInsertIndexTuples() needs to be
freed otherwise lots of lists (one per row) will build up and not be freed
until the end of the query. This actually accounts for even more memory
than the after-trigger event queue. Patch attached.
Of course the
On 31 January 2010 16:03, Tom Lane t...@sss.pgh.pa.us wrote:
Dean Rasheed dean.a.rash...@googlemail.com writes:
Oops, my fault. The list returned by ExecInsertIndexTuples() needs to be
freed otherwise lots of lists (one per row) will build up and not be freed
until the end of the query
On 31 March 2010 06:58, Dmitry Fefelov fo...@ac-sw.com wrote:
For now Postgres able to create deferrable uniques with following syntax:
...
and table_constraint is:
[ CONSTRAINT constraint_name ]
{ UNIQUE ( column_name [, ... ] ) index_parameters |
PRIMARY KEY ( column_name [, ... ] )
While looking at this report
http://archives.postgresql.org/pgsql-bugs/2009-08/msg00083.php
I spotted another error message which could use improvement:
CREATE TABLE foo(a int PRIMARY KEY DEFERRABLE);
CREATE TABLE bar(a int REFERENCES foo(a));
ERROR: there is no unique constraint matching
I've started looking at the following TODO item:
Improve deferrable unique constraints for cases with many conflicts
and Tom's suggestion that the rows to be checked can be stored in a
bitmap, which would become lossy when the number of rows becomes large
enough. There is also another TODO
2009/10/19 Robert Haas robertmh...@gmail.com:
On Mon, Oct 19, 2009 at 12:48 PM, Dean Rasheed
dean.a.rash...@googlemail.com wrote:
This is a WIP patch to replace the after-trigger queues with TID bitmaps
to prevent them from using excessive amounts of memory. Each round of
trigger executions
2009/10/25 Simon Riggs si...@2ndquadrant.com:
On Mon, 2009-10-19 at 17:48 +0100, Dean Rasheed wrote:
This is a WIP patch to replace the after-trigger queues with TID bitmaps
to prevent them from using excessive amounts of memory. Each round of
trigger executions is a modified bitmap heap scan
2009/10/25 Jeff Davis pg...@j-davis.com:
On Mon, 2009-10-19 at 17:48 +0100, Dean Rasheed wrote:
This is a WIP patch to replace the after-trigger queues with TID bitmaps
to prevent them from using excessive amounts of memory. Each round of
trigger executions is a modified bitmap heap scan
2009/10/26 Simon Riggs si...@2ndquadrant.com:
On Mon, 2009-10-26 at 13:28 +, Dean Rasheed wrote:
It works for all kinds of trigger events,
and is intended as a complete drop-in replacement for the after
triggers queue.
All of those seem false in the general case. What will you do
2009/10/26 Jeff Davis pg...@j-davis.com:
On Mon, 2009-10-26 at 13:41 +, Dean Rasheed wrote:
I did a quick bit of testing, and I think that there is a
locking/concurrency problem :-(
Unfortunately I can't reproduce the problem on my machine; it always
passes.
That's odd. It happens
2009/11/3 Tom Lane t...@sss.pgh.pa.us:
Jeff Davis pg...@j-davis.com writes:
I'm not excited about using NOT, because I think it has a hint of a
double-negative when combined with EXCLUSION.
Well, the choice of EXCLUSION isn't set in stone either ...
Is this really a generalized uniqueness
This was originally because I wanted a convenient way to see the
execution plan of SQL queries run from stored procedures -
http://archives.postgresql.org/pgsql-performance/2008-01/msg00245.php
My original patch is fairly basic - it adds a new parameter
debug_explain_plan which is similar to
Hi,
This is a small patch I posted a few months back, and then kinda forgot
about / got distracted with other things.
Is there any interest in this? If so I am willing to put more work into
it, if people like it or have suggested improvements. Otherwise I'll let it
drop.
Here's what is does:
Its certainly not useful to *me* in its current form. It would
produce way to much (usless) output. However if it were tied to
log_min_duration_statement so I get auto explains for long running
queries... That would be very useful indeed. Even if it has to
explain everything just to toss out
Here is an updated version of the patch, with a debug_explain_min_duration
parameter to allow explaining of just slow-running queries. I've also
incorporated
a couple of Simon Riggs' suggestions for formatting the output better.
Do I need to post this to -patches, or is that now obsolete?
OK, this one should work against CVS HEAD.
Dean.
Subject: Re: [HACKERS] Auto-explain patch From: [EMAIL PROTECTED] To:
[EMAIL PROTECTED] CC: pgsql-hackers@postgresql.org Date: Sun, 6 Jul 2008
16:42:55 +0100 On Thu, 2008-07-03 at 16:58 +, Dean Rasheed wrote:
Here is an updated
, and if both are off, then the sql_trace
parameters would do nothing.
Dean
Subject: RE: [HACKERS] Auto-explain patch
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: pgsql-hackers@postgresql.org
Date: Mon, 7 Jul 2008 18:03:15 +0100
On Sun, 2008-07-06 at 17:58 +, Dean Rasheed wrote:
OK
Just set client_min_messages = 'LOG';
True, but you would still need to be a superuser to to set the min_durations and
explain parameters. The other advantage of client_sql_trace is that you could
debug your own functions without filling up the log file. It would work better
for
multiple users
+0300
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [HACKERS] Auto-explain patch
CC: [EMAIL PROTECTED]; [EMAIL PROTECTED]; pgsql-hackers@postgresql.org
On 7/9/08, ITAGAKI Takahiro wrote:
Dean Rasheed wrote:
* client_sql_trace = on | off - settable by a normal user to allow
After sleeping on this, I think we should follow your idea.
Hmm. I preferred your idea ;-) It reduces the number of new parameters
back down to 3, which makes it easier to use:
* trace_min_planner_duration - int, PGC_USERSET
* trace_min_executor_duration - int, PGC_USERSET
*
Ooops. That last patch had an embarrassing little typo which caused it to not
actually record the planner times.
This new version fixes that and also includes a little patch to psql so that it
ignores any backend notices during tab-completion, which otherwise just get
in the way. Trace during
Thanks for the feedback, and sorry for my delay in replying (I was on
holiday).
Tom Lane wrote:
Comments:
I do not think that you should invent a new elog level for this, and
especially not one that is designed to send unexpected messages to the
client. Having to kluge tab completion like
Here is a contrib version of auto-explain.
OK, I hadn't considered doing it as a module before.
Is it only available to superusers? Do we have a general policy on
this? Most logging options are superuser-only, but the recent changes
to LOG debug_print_* output have left them PGC_USERSET.
On 3 June 2010 02:06, Bruce Momjian br...@momjian.us wrote:
Also, foreign keys can't be defined that refer to a deferrable primary
key. That isn't mentioned at all in the manual with regard to the
DEFERRABLE clause, though it is mentioned in the FK section. You get
this error message
ERROR:
Hi,
I just spotted that the docs for ALTER TABLE .. DISABLE/ENABLE TRIGGER
are out of date, now that we have deferrable uniqueness and exclusion
constraints.
Also, I think that the original comment in the ENABLE/DISABLE TRIGGER
section was misleading because it suggested that only superusers can
On 7 June 2010 15:56, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Sabino Mullane g...@turnstep.com writes:
I don't think the above would be particularly hard to implement myself,
but if it becomes a really big deal, we can certainly punt by simply
quoting anything containing an indicator (the
On 17 July 2010 20:19, Tom Lane t...@sss.pgh.pa.us wrote:
... For instance, if x is 1e8 * y, then y*y
fails to affect the sum at all (given typical float8 arithmetic), and
you'll get back sqrt(x*x) even though y should have been able to affect
the result at the 8th place or so. In the
On 4 August 2010 13:22, Marko Tiikkaja marko.tiikk...@cs.helsinki.fi wrote:
On 8/4/10 2:39 PM +0300, Dean Rasheed wrote:
Does this sound like a useful feature? Is this a sane approach to
implementing it? If not, has anyone else given any thought as to how
it might be implemented?
I didn't
On 4 August 2010 14:43, Marko Tiikkaja marko.tiikk...@cs.helsinki.fi wrote:
3) You can't set the RETURNING results. You suggested that
RETURNING for DELETE would return the OLD value, but that seems
broken because that's not necessarily what was deleted.
Well that's what
On 4 August 2010 15:08, Marko Tiikkaja marko.tiikk...@cs.helsinki.fi wrote:
On 8/4/10 5:03 PM +0300, Dean Rasheed wrote:
On 4 August 2010 14:43, Marko Tiikkajamarko.tiikk...@cs.helsinki.fi
wrote:
I'm not sure I understand. RETURNING in DELETE on a table fetches the
old
value after
On 7 August 2010 10:56, Marko Tiikkaja marko.tiikk...@cs.helsinki.fi wrote:
The problem is that this isn't even nearly sufficient. I gave this some
more thought while I was away, and it seems that I missed at least one more
important thing: the WHERE clause. Imagine this query:
DELETE FROM
On 14 August 2010 13:12, Marko Tiikkaja marko.tiikk...@cs.helsinki.fi wrote:
On 2010-08-08 1:45 PM +0300, I wrote:
On 8/8/2010 12:49 PM, Dean Rasheed wrote:
For those migrating code from Oracle, providing this feature as-is
might be valuable, since presumably they are not too concerned about
On 14 August 2010 23:22, Dean Rasheed dean.a.rash...@gmail.com wrote:
I'll try to post an updated patch then, with some real trigger code,
I've moved this to a new thread, with a WIP patch that allow 3 types
of triggers to be added to VIEWs:
http://archives.postgresql.org/pgsql-hackers/2010-08
On 16 August 2010 14:45, David Fetter da...@fetter.org wrote:
Please add this to the next commitfest :)
Done.
Thanks,
Dean
https://commitfest.postgresql.org/action/commitfest_view?id=7
Cheers,
David.
--
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778 AIM:
On 15 August 2010 18:38, Dean Rasheed dean.a.rash...@gmail.com wrote:
There are still a number of things left todo:
- extend ALTER VIEW with enable/disable trigger commands
On further reflection, I wonder if the ability to disable VIEW
triggers is needed/wanted at all. I just noticed
On 16 August 2010 18:50, Tom Lane t...@sss.pgh.pa.us wrote:
Dean Rasheed dean.a.rash...@gmail.com writes:
On 15 August 2010 18:38, Dean Rasheed dean.a.rash...@gmail.com wrote:
There are still a number of things left todo:
- extend ALTER VIEW with enable/disable trigger commands
On further
While testing triggers, I came across the following memory leak.
Here's a simple test case:
CREATE TABLE foo(a int);
CREATE OR REPLACE FUNCTION trig_fn() RETURNS trigger AS
$$
BEGIN
RETURN NEW;
END;
$$
LANGUAGE plpgsql;
CREATE TRIGGER ins_trig BEFORE INSERT ON foo
FOR EACH ROW EXECUTE
On 7 August 2010 03:51, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
Next version. Changed dependencies to pg_constraint, removed handling
of unique constraints for now, and made some enhancements so that views
track dependencies on constraints even in
On 5 September 2010 16:15, Tom Lane t...@sss.pgh.pa.us wrote:
Dean Rasheed dean.a.rash...@gmail.com writes:
On 7 August 2010 03:51, Tom Lane t...@sss.pgh.pa.us wrote:
I was testing out this feature this morning and discovered that the
results may be non-deterministic if the PK is deferrable
On 7 September 2010 02:03, David Christensen da...@endpoint.com wrote:
On Sep 5, 2010, at 3:09 AM, Dean Rasheed wrote:
On 15 August 2010 18:38, Dean Rasheed dean.a.rash...@gmail.com wrote:
Here is a WIP patch implementing triggers on VIEWs ... snip
There are still a number of things left
, Dean Rasheed wrote:
For potential uniqueness violations a
deferred trigger is queued to do a full check at the end of the
statement or transaction, or when SET CONSTRAINTS is called. The
trigger then replays the insert in a fake insert mode, which doesn't
actually insert anything - it just checks
Tom Lane wrote:
... I think it might be interesting to turn
around Jeff's syntax sketch and provide a way to say that a CONSTRAINT
declaration should depend on some previously added index, eg
something like
ALTER TABLE tab ADD CONSTRAINT UNIQUE (col1, col2) USING index
Is there
Jeff Davis wrote:
On Tue, 2009-07-07 at 19:38 +0100, Dean Rasheed wrote:
This approach works well if the number of potential conflicts is
small.
[...]
Curing the scalability problem by spooling the queue to disk shouldn't
be too hard to do, but that doesn't address the problem
2009/7/14 Alvaro Herrera alvhe...@commandprompt.com:
Jeff Davis wrote:
The only problem there is telling the btree AM whether or not to do the
insert or not (i.e. fake versus real insert). Perhaps you can just do
that with careful use of a global variable?
Sure, all of this is a little
2009/7/15 Tom Lane t...@sss.pgh.pa.us:
There is no reason at all to avoid an index AM API change if one is
useful.
Thinking about this a bit more, perhaps it would be better if I added
an out parameter to the AM for the uniqueness result, rather than
overloading the return value, which is quite
2009/7/20 Alvaro Herrera alvhe...@commandprompt.com:
Dean Rasheed wrote:
Thanks for the thorough review. I attach an new version of the patch,
updated to HEAD, and with the index AM change discussed.
Wow, this is a large patch.
I didn't do a thorough review, but some quickies I noticed
2009/7/20 David Fetter da...@fetter.org:
On Mon, Jul 20, 2009 at 10:21:53AM -0400, Tom Lane wrote:
Dean Rasheed dean.a.rash...@googlemail.com writes:
* Please move the code that says that it should be in a new file to a
new file.
Ah yes, I forgot about that. Will do.
utils/adt
2009/7/20 Alvaro Herrera alvhe...@commandprompt.com:
Seems related to the new list in AfterTriggerSaveEvent, which is
used in ways that seem to conflict with its header comment ...
Reading the comment for that function, I think it is quite misleading
- mainly because the meaning of the word
2009/7/21 Jeff Davis pg...@j-davis.com:
On Mon, 2009-07-20 at 17:24 +0100, Dean Rasheed wrote:
The same argument could be applied to ruleutils.c, trigfuncs.c and perhaps
one or two others.
And if not there, where then?
I'm moving the patch status back to waiting on author until Alvaro's
2009/7/22 Dean Rasheed dean.a.rash...@googlemail.com:
OK, here's an updated patch.
In case it's not obvious, I've opted for backend/commands for the new file.
- Dean
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
2009/7/27 Jeff Davis pg...@j-davis.com:
On Mon, 2009-07-27 at 13:14 -0400, Tom Lane wrote:
The main thing that is bothering me is something Dean pointed out at
the very beginning: the patch will not scale well for large numbers of
conflicts.
I'd pefer to take option #3, and I want to try to
2009/7/27 Tom Lane t...@sss.pgh.pa.us:
Jeff Davis pg...@j-davis.com writes:
The way I see it, there are two strategies:
(a) build up a list as you go, and check it later
(b) do a check of the full table at once
The patch seems like a reasonable implementation of (a), so what it's
2009/7/27 Tom Lane t...@sss.pgh.pa.us:
(In fact, in a real sense these ARE join problems ... maybe we should
stop thinking of them as fire-a-bunch-of-triggers and instead think of
executing a single check query with appropriate WHERE clause ...)
Hmm. Presumably that is the same WHERE clause
2009/7/27 Jeff Davis pg...@j-davis.com:
On Mon, 2009-07-27 at 16:33 -0400, Tom Lane wrote:
If we did add another column to pg_trigger, I'd be a bit tempted to add
one to pg_constraint too. tgconstrrelid for RI triggers is a mirror of
a pg_constraint column, and it seems like the index data
2009/7/28 Tom Lane t...@sss.pgh.pa.us:
[sigh, forgot to cc hackers the first time ]
Foreign key behavior is only sane if the referenced column(s) are
unique. With the proposed patch, it is possible that the uniqueness
check on the referenced columns is deferred, which means it might not
2009/7/28 Tom Lane t...@sss.pgh.pa.us:
... speaking of adding catalog columns, I just discovered that the patch
adds searches of pg_depend and pg_constraint to BuildIndexInfo. This
seems utterly unacceptable on two grounds:
* It's sheer luck that it gets through bootstrap without crashing.
2009/7/29 Tom Lane t...@sss.pgh.pa.us:
Another thought on the index AM API issues: after poking through the
code I realized that there is *nobody* paying any attention to the
existing bool result of aminsert() (ie, did we insert anything or not).
So I think that instead of adding a bool*
2009/7/29 Tom Lane t...@sss.pgh.pa.us:
Dean Rasheed dean.a.rash...@googlemail.com writes:
[ deferrable unique constraints patch ]
Applied after rather extensive editorialization.
Excellent! Thanks for all your work sorting out my rookie mistakes. I
haven't had a chance to go through all your
On 23 January 2012 20:14, Pavel Stehule pavel.steh...@gmail.com wrote:
Hello
2012/1/23 Robert Haas robertmh...@gmail.com:
On Tue, Jan 3, 2012 at 2:49 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
jup, we can continue in enhancing step by step.
I change a patch and now ALTER TABLE,
Given a freshly created table (not vacuumed), and a query that uses an
index-only scan, for example:
CREATE TABLE foo(a int PRIMARY KEY);
INSERT INTO foo SELECT * FROM generate_series(1,100);
ANALYSE foo;
EXPLAIN ANALYSE SELECT count(*) FROM foo WHERE a = 1;
On 31 January 2012 17:35, Robert Haas robertmh...@gmail.com wrote:
On Sun, Jan 29, 2012 at 2:47 AM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
Given a freshly created table (not vacuumed), and a query that uses an
index-only scan, for example:
CREATE TABLE foo(a int PRIMARY KEY);
INSERT
On 31 January 2012 19:49, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jan 31, 2012 at 2:15 PM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
In the case when we're asked to clear a bit, it would first try to pin
the relevant page, which would go through vm_readbuf() with extend set
On 31 January 2012 23:04, Tom Lane t...@sss.pgh.pa.us wrote:
Dean Rasheed dean.a.rash...@gmail.com writes:
The thing I'm unsure about is whether sending sinval
messages when the visibility map is extended is a good idea.
Seems perfectly reasonable to me. They'd occur so seldom as to be
more
On 2 February 2012 01:40, Robert Haas robertmh...@gmail.com wrote:
On Wed, Feb 1, 2012 at 7:44 PM, Robert Haas robertmh...@gmail.com wrote:
So, I guess the trade-off here is that, since sinval messages aren't
processed immediately, we often won't notice the VM extension until
the next
On 8 December 2012 15:21, Tom Lane t...@sss.pgh.pa.us wrote:
Continuing to work on this ... I found multiple things I didn't like
about the permission-field update code. Attached are some heavily
commented extracts from the code as I've changed it. Does anybody
object to either the code or
On 8 December 2012 23:29, Tom Lane t...@sss.pgh.pa.us wrote:
Dean Rasheed dean.a.rash...@gmail.com writes:
Attached is a rebased patch using new OIDs.
Applied after a fair amount of hacking.
Awesome! Thank you very much.
Regards,
Dean
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On 9 December 2012 16:53, Tom Lane t...@sss.pgh.pa.us wrote:
Thom Brown t...@linux.com writes:
One observation: There doesn't appear to be any tab-completion for view
names after DML statement keywords in psql. Might we want to add this?
Well, there is, but it only knows about INSTEAD OF
On 9 December 2012 22:00, Tom Lane t...@sss.pgh.pa.us wrote:
Dean Rasheed dean.a.rash...@gmail.com writes:
It's a shame though that pg_view_is_updatable() and
pg_view_is_insertable() are not really useful for identifying
potentially updatable views (e.g., consider an auto-updatable view
On 21 December 2012 08:56, Simon Riggs si...@2ndquadrant.com wrote:
It's unreasonable for people to demand a feature yet provide no
guidance to the person trying (hard) to provide that feature in a
sensible way. If people genuinely believe case (2) is worth pursuing,
additional work and input
On 21 December 2012 09:29, Dean Rasheed dean.a.rash...@gmail.com wrote:
On 21 December 2012 08:56, Simon Riggs si...@2ndquadrant.com wrote:
It's unreasonable for people to demand a feature yet provide no
guidance to the person trying (hard) to provide that feature in a
sensible way. If people
I've been thinking about WITH CHECK OPTION for auto-updatable views.
Given the timing I doubt if this will be ready for 9.3, since I only
get occasional evenings and weekends to hack on postgres, but I think
it's probably worth kicking off a discussion, starting with a
description of what the
On 5 January 2013 16:58, Magnus Hagander mag...@hagander.net wrote:
Attached is an updated version of the patch, per the comments from Tom
and rebased on top of the current master. Since it's been a long time
ago, and some code churn in the area, another round of review is
probably a good
On 3 January 2013 13:49, Ali Dar ali.munir@gmail.com wrote:
Find attached an initial patch for ALTER RENAME RULE feature. Please note
that it does not have any documentation yet.
Hi,
I just got round to looking at this. All-in-all it looks OK. I just
have a few more review comments, in
On 26 January 2013 10:58, Pavel Stehule pavel.steh...@gmail.com wrote:
updated patches due changes for better variadic any function.
apply fix_mixing_positinal_ordered_placeholders_warnings_20130126.patch first
Hi,
No one is listed as a reviewer for this patch so I thought I would
take a
On 28 January 2013 17:32, Stephen Frost sfr...@snowman.net wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Both. If we had done this when we first implemented format(), it'd be
fine, but it's too late to change it now. There very likely are
applications out there that depend on the current
On 28 January 2013 20:40, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/1/28 Dean Rasheed dean.a.rash...@gmail.com:
On 28 January 2013 17:32, Stephen Frost sfr...@snowman.net wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Both. If we had done this when we first implemented format(), it'd
On 28 January 2013 20:32, Dean Rasheed dean.a.rash...@gmail.com wrote:
In general a format specifier looks like:
%[parameter][flags][width][.precision][length]type
This highlights another problem with the current implementation ---
the '-' flag and the width field need to be parsed separately
On 29 January 2013 08:19, Dean Rasheed dean.a.rash...@gmail.com wrote:
* The width field is optional, even if the '-' flag is specified. So
'%-s' is perfectly legal and should be interpreted as '%s'. The
current implementation treats it as a width of 0, which is wrong.
Oh, but of course
On 24 June 2012 04:01, Alvaro Herrera alvhe...@commandprompt.com wrote:
Excerpts from Dean Rasheed's message of sáb jun 23 18:08:31 -0400 2012:
I spotted a couple of other issues during testing:
David, when you generate a new version of the patch, please also make
sure to use
I've been looking at this further and I have made some improvements,
but also found a problem.
On 1 July 2012 23:35, Dean Rasheed dean.a.rash...@gmail.com wrote:
I'm also aware that my new function ChangeVarAttnos() is almost
identical to the function map_variable_attnos() that Tom recently
On 27 August 2012 19:09, Bruce Momjian br...@momjian.us wrote:
Any status on this?
Tom took care of it in the last commitfest -
http://archives.postgresql.org/pgsql-hackers/2012-06/msg01075.php
I think that todo item can now be marked as done.
Regards,
Dean
--
Sent via pgsql-hackers
On 27 August 2012 20:42, Bruce Momjian br...@momjian.us wrote:
On Mon, Aug 27, 2012 at 08:35:00PM +0100, Dean Rasheed wrote:
On 27 August 2012 19:09, Bruce Momjian br...@momjian.us wrote:
Any status on this?
Tom took care of it in the last commitfest -
http://archives.postgresql.org
On 27 August 2012 20:26, Dean Rasheed dean.a.rash...@gmail.com wrote:
Here's an updated WIP patch which I'll add to the next commitfest.
Re-sending gzipped (apparently the mail system corrupted it last time).
Regards,
Dean
auto-update-views.patch.gz
Description: GNU Zip compressed data
On 30 August 2012 20:05, Robert Haas robertmh...@gmail.com wrote:
On Sun, Aug 12, 2012 at 5:14 PM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
None of this new code kicks in for non-security barrier views, so the
kinds of plans I posted upthread remain unchanged in that case. But
now
On 31 August 2012 07:59, Dean Rasheed dean.a.rash...@gmail.com wrote:
On 30 August 2012 20:05, Robert Haas robertmh...@gmail.com wrote:
On Sun, Aug 12, 2012 at 5:14 PM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
None of this new code kicks in for non-security barrier views, so the
kinds
On 17 July 2012 05:02, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/7/17 Robert Haas robertmh...@gmail.com:
On Sun, Jul 15, 2012 at 5:52 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
The attached patch is a revised version of row-level security feature.
...
According to the Robert's comment, I
Hi,
Unless I'm missing something, it is not possible in psql to tell
whether a view has the security_barrier option. I think that this is
something that ought to be possible from psql, otherwise the new
feature is not visible.
This patch displays any reloptions for a view at the end, if \d+ is
On 3 September 2012 14:48, Tom Lane t...@sss.pgh.pa.us wrote:
Dean Rasheed dean.a.rash...@gmail.com writes:
Unless I'm missing something, it is not possible in psql to tell
whether a view has the security_barrier option. I think that this is
something that ought to be possible from psql
On 18 September 2012 14:23, Amit kapila amit.kap...@huawei.com wrote:
Please find the review of the patch.
Thanks for the review. Attached is an updated patch, and I've include
some responses to specific review comments below.
Extra test cases that can be added to regression suite are as
On 8 October 2012 15:57, Kohei KaiGai kai...@kaigai.gr.jp wrote:
The attached patch is a refreshed version towards the latest master branch,
to fix up patch conflicts.
Here is no other difference from the previous revision.
Thanks,
I had another look at this over the weekend and I found
1 - 100 of 605 matches
Mail list logo
