Pavel Stehule escribió:
I though about it too. But I didn't continue - reasons was named by Dean -
and RemoveObjects are not difficult code - lot of code is mechanical - and
it is not on critical path.
I have pushed it after some editorialization.
--
Álvaro Herrera
Hello
2014/1/22 Dean Rasheed dean.a.rash...@gmail.com
On 21 January 2014 22:28, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
I have been mulling over this patch, and I can't seem to come to terms
with it. I first started making it look nicer here and there, thinking
it was all mostly
I have been mulling over this patch, and I can't seem to come to terms
with it. I first started making it look nicer here and there, thinking
it was all mostly okay, but eventually arrived at the idea that it seems
wrong to do what this does: basically, get_object_address() tries to
obtain an
On 21 January 2014 22:28, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
I have been mulling over this patch, and I can't seem to come to terms
with it. I first started making it look nicer here and there, thinking
it was all mostly okay, but eventually arrived at the idea that it seems
wrong
2013/12/8 Dean Rasheed dean.a.rash...@gmail.com
On 7 December 2013 21:34, Pavel Stehule pavel.steh...@gmail.com wrote:
Well I was basically proposing that does_not_exist_skipping() be
enhanced to report on non-existent types that form part of the object
specification. I think this would
Hello
2013/12/5 Peter Eisentraut pete...@gmx.net
Can someone in this thread clarify the commit fest situation? I see two
entries that appear to be the same:
https://commitfest.postgresql.org/action/patch_view?id=1174
https://commitfest.postgresql.org/action/patch_view?id=1175
I think
2013/12/5 Dean Rasheed dean.a.rash...@gmail.com
On 5 December 2013 01:33, Peter Eisentraut pete...@gmx.net wrote:
Can someone in this thread clarify the commit fest situation? I see two
entries that appear to be the same:
https://commitfest.postgresql.org/action/patch_view?id=1174
On 5 December 2013 10:06, Pavel Stehule pavel.steh...@gmail.com wrote:
I think #1175 is close to being ready for commit. Pavel, will you
produce an updated patch based on our last discussion? I'll set this
patch to waiting on author.
I expected so your version was a final. I have no problem
On 2 December 2013 04:55, Pavel Stehule pavel.steh...@gmail.com wrote:
Hello
it looks well, thank you
Regards
Pavel
I've been thinking about this some more, and there's another case that
concerns me slightly. We're now making some of the DROP...IF EXISTS
commands tolerate non-existent
2013/12/4 Dean Rasheed dean.a.rash...@gmail.com
On 2 December 2013 04:55, Pavel Stehule pavel.steh...@gmail.com wrote:
Hello
it looks well, thank you
Regards
Pavel
I've been thinking about this some more, and there's another case that
concerns me slightly. We're now making
Can someone in this thread clarify the commit fest situation? I see two
entries that appear to be the same:
https://commitfest.postgresql.org/action/patch_view?id=1174
https://commitfest.postgresql.org/action/patch_view?id=1175
I think the first one is a duplicate or obsolete.
--
Sent via
On 5 December 2013 01:33, Peter Eisentraut pete...@gmx.net wrote:
Can someone in this thread clarify the commit fest situation? I see two
entries that appear to be the same:
https://commitfest.postgresql.org/action/patch_view?id=1174
Dean Rasheed escribió:
+/*
+ * If a schema was explicitly specified, test if it exists. If it does not,
+ * report the schema as missing rather than the child object.
+ */
+static bool
+schema_does_not_exist_skipping(List *objname,
+
On 2 December 2013 19:37, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Dean Rasheed escribió:
+/*
+ * If a schema was explicitly specified, test if it exists. If it does not,
+ * report the schema as missing rather than the child object.
+ */
+static bool
Dean Rasheed escribió:
I think that memory gets freed at the end of the DROP command, so I
don't think this is a concern. In any case, that RangeVar is only of
order 50 bytes. If we were concerned about memory leakage here, a
bigger concern would be the calling code in
On 12/1/13, 2:32 AM, Pavel Stehule wrote:
trailing whitespace
fixed,
Peter, what application do you use for this check?
git diff --check
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 1 December 2013 07:32, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/11/30 Peter Eisentraut pete...@gmx.net
trailing whitespace
fixed,
Hi,
I've been looking at this and I think it's mostly in good shape, but I
spotted a few minor issues:
* There's a typo in the notice text in a
Hello
it looks well, thank you
Regards
Pavel
2013/12/1 Dean Rasheed dean.a.rash...@gmail.com
On 1 December 2013 07:32, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/11/30 Peter Eisentraut pete...@gmx.net
trailing whitespace
fixed,
Hi,
I've been looking at this
On Fri, 2013-11-29 at 09:06 +0100, Pavel Stehule wrote:
attached patch implement unified behave for DROP IF EXISTS statements
as was discussed
src/backend/catalog/namespace.c:1743: indent with spaces.
src/backend/commands/dropcmds.c:322: indent with spaces.
2013/11/30 Peter Eisentraut pete...@gmx.net
trailing whitespace
fixed,
Peter, what application do you use for this check?
Regards
Pavel
commit 88e0a6b97968f88aaa1e3cef17fc2e6e2ca9f25d
Author: Pavel Stehule pavel.steh...@gooddata.com
Date: Fri Nov 29 11:10:07 2013 +0100
initial
diff
I'll prepare patch
2013/11/27 Tom Lane t...@sss.pgh.pa.us
Dean Rasheed dean.a.rash...@gmail.com writes:
Actually the IF EXISTS in DROP TABLE now applies to the schema as
well. Unfortunately there is currently no consistency across the
various DROP commands --- some tolerate a
Hello
2013/11/27 Tom Lane t...@sss.pgh.pa.us
Dean Rasheed dean.a.rash...@gmail.com writes:
Actually the IF EXISTS in DROP TABLE now applies to the schema as
well. Unfortunately there is currently no consistency across the
various DROP commands --- some tolerate a non-existent schema,
On 11/24/13, 2:28 PM, Pavel Stehule wrote:
Note: DROP TRIGGER ON tablename is PostgreSQL feature - no other
databases (without PostgreSQL forks) uses this syntax - so we don't need
thinking what is in (or what will be) in ANSI standard (or what other
databases does). In this moment syntax of
On 26 November 2013 19:54, Peter Eisentraut pete...@gmx.net wrote:
On 11/24/13, 2:28 PM, Pavel Stehule wrote:
Note: DROP TRIGGER ON tablename is PostgreSQL feature - no other
databases (without PostgreSQL forks) uses this syntax - so we don't need
thinking what is in (or what will be) in ANSI
Dean Rasheed dean.a.rash...@gmail.com writes:
Actually the IF EXISTS in DROP TABLE now applies to the schema as
well. Unfortunately there is currently no consistency across the
various DROP commands --- some tolerate a non-existent schema, while
others error out.
Yeah. I think now that we've
2013/11/21 Peter Eisentraut pete...@gmx.net
On 11/21/13, 2:35 AM, Pavel Stehule wrote:
I am feeling, so almost all people prefer
DROP TRIGGER [ IF EXISTS ] name ON table_name [ CASCADE | RESTRICT ];
Can we live with it?
Fine with me.
I think it helps if you consider IF EXISTS an
On 11/21/13, 2:35 AM, Pavel Stehule wrote:
I am feeling, so almost all people prefer
DROP TRIGGER [ IF EXISTS ] name ON table_name [ CASCADE | RESTRICT ];
Can we live with it?
Fine with me.
I think it helps if you consider IF EXISTS an attribute of the command,
not an attribute of the
On 2013-11-21 17:14:17 -0500, Peter Eisentraut wrote:
On 11/21/13, 2:35 AM, Pavel Stehule wrote:
I am feeling, so almost all people prefer
DROP TRIGGER [ IF EXISTS ] name ON table_name [ CASCADE | RESTRICT ];
Can we live with it?
Fine with me.
I think it helps if you consider
Hello
2013/11/19 Robert Haas robertmh...@gmail.com
On Tue, Nov 19, 2013 at 3:53 AM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
1). Keep the existing syntax:
DROP TRIGGER [ IF EXISTS ] name ON table_name [ CASCADE | RESTRICT ];
but make it tolerate a non-existent table when IF
On 12 November 2013 16:00, Pavel Stehule pavel.steh...@gmail.com wrote:
Hello
here is patch with fault tolerant drop trigger and drop rule support
drop trigger [if exists] trgname on [if exists] tablename;
drop rule [if exists] trgname on [if exists] tablename;
Regards
Pavel
Hi,
I
Hello
I am thinking so @2 is not good idea. Using well known idiom IF EXISTS
once before table name and second after table name can be difficult and
messy for users. If you like it, use different idiom or different keyword,
please.
My person favourite is @1 - fault tolerant version - but I
On Tue, Nov 19, 2013 at 3:53 AM, Dean Rasheed dean.a.rash...@gmail.com wrote:
1). Keep the existing syntax:
DROP TRIGGER [ IF EXISTS ] name ON table_name [ CASCADE | RESTRICT ];
but make it tolerate a non-existent table when IF EXISTS is specified.
I don't love this option, but I like it
Hello
here is patch with fault tolerant drop trigger and drop rule support
drop trigger [if exists] trgname on [if exists] tablename;
drop rule [if exists] trgname on [if exists] tablename;
Regards
Pavel
2013/11/11 Pavel Stehule pavel.steh...@gmail.com
2013/11/11 Tom Lane
I can agree, so DROP TRIGGER doesn't need a IF EXISTS clause when it is
executed after DROP TABLE.
pg_dump -c produces:
DROP TRIGGER jjj ON public.foo;
DROP TABLE public.foo;
DROP FUNCTION public.f1();
DROP EXTENSION plpgsql;
DROP SCHEMA public;
Is there some reason why we use explicitly DROP
2013/11/11 Tom Lane t...@sss.pgh.pa.us
Andres Freund and...@2ndquadrant.com writes:
Turns out that's bogus - ALTER TABLE has two levels of NOT EXISTS.
Maybe we should just do the same for DROP TRIGGER?
DROP TRIGGER [ IF EXISTS ] name ON table_name [ IF EXISTS ] [ CASCADE |
RESTRICT ]
2013/11/11 Pavel Stehule pavel.steh...@gmail.com
2013/11/11 Tom Lane t...@sss.pgh.pa.us
Andres Freund and...@2ndquadrant.com writes:
Turns out that's bogus - ALTER TABLE has two levels of NOT EXISTS.
Maybe we should just do the same for DROP TRIGGER?
DROP TRIGGER [ IF EXISTS ] name
[ catching up on old email ]
Andres Freund and...@2ndquadrant.com writes:
On 2013-10-15 00:23:15 +0200, Tomas Vondra wrote:
On 2013-10-10 12:54:23 -0400, Andrew Dunstan wrote:
This thread seems to have gone cold, but I'm inclined to agree with
Pavel. If the table doesn't exist, neither does
On 2013-11-10 16:28:27 -0500, Tom Lane wrote:
[ catching up on old email ]
Andres Freund and...@2ndquadrant.com writes:
On 2013-10-15 00:23:15 +0200, Tomas Vondra wrote:
On 2013-10-10 12:54:23 -0400, Andrew Dunstan wrote:
This thread seems to have gone cold, but I'm inclined to agree
Andres Freund and...@2ndquadrant.com writes:
On 2013-11-10 16:28:27 -0500, Tom Lane wrote:
I think this is nonsense. It's only one step removed from why do you
need IF EXISTS at all, you should know whether the object is there.
The entire point of this syntax is to not need to do detailed
On 2013-11-10 18:16:16 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-11-10 16:28:27 -0500, Tom Lane wrote:
I think this is nonsense. It's only one step removed from why do you
need IF EXISTS at all, you should know whether the object is there.
The entire
Andres Freund and...@2ndquadrant.com writes:
On 2013-11-10 18:16:16 -0500, Tom Lane wrote:
Then I take it you also think we should undo the changes that made
DROP TABLE IF EXISTS foo.bar not fail if schema foo doesn't exist?
Because after all, the schema is not the object being dropped.
No,
On 2013-11-10 18:26:26 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-11-10 18:16:16 -0500, Tom Lane wrote:
Then I take it you also think we should undo the changes that made
DROP TABLE IF EXISTS foo.bar not fail if schema foo doesn't exist?
Because after all,
Andres Freund and...@2ndquadrant.com writes:
... So we'd get approximately one line further unless we fix this for DROP
DEFAULT and DROP CONSTRAINT as well.
True. As far as pg_dump --clean is concerned, it'd undoubtedly be easier
if we did what you suggest and just eliminate the emitted DROP
On 2013-11-10 18:42:11 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
... So we'd get approximately one line further unless we fix this for DROP
DEFAULT and DROP CONSTRAINT as well.
Turns out that's bogus - ALTER TABLE has two levels of NOT EXISTS.
Maybe we should just
Andres Freund and...@2ndquadrant.com writes:
Turns out that's bogus - ALTER TABLE has two levels of NOT EXISTS.
Maybe we should just do the same for DROP TRIGGER?
DROP TRIGGER [ IF EXISTS ] name ON table_name [ IF EXISTS ] [ CASCADE |
RESTRICT ]
Works for me.
On Tue, Oct 22, 2013 at 9:37 PM, Josh Kupershmidt schmi...@gmail.com wrote:
On Mon, Oct 14, 2013 at 5:38 PM, Josh Kupershmidt schmi...@gmail.com wrote:
Also, Pavel, this patch is still listed as 'Needs Review' in the CF
app, but I haven't seen a response to the concerns in my last message.
It
2013/10/24 Robert Haas robertmh...@gmail.com
On Tue, Oct 22, 2013 at 9:37 PM, Josh Kupershmidt schmi...@gmail.com
wrote:
On Mon, Oct 14, 2013 at 5:38 PM, Josh Kupershmidt schmi...@gmail.com
wrote:
Also, Pavel, this patch is still listed as 'Needs Review' in the CF
app, but I haven't seen
On Mon, Oct 14, 2013 at 5:38 PM, Josh Kupershmidt schmi...@gmail.com wrote:
Also, Pavel, this patch is still listed as 'Needs Review' in the CF
app, but I haven't seen a response to the concerns in my last message.
It looks like this patch has been imported into the 2013-11 CF [1] and
marked
On Thu, Oct 10, 2013 at 12:54 PM, Andrew Dunstan and...@dunslane.net wrote:
This thread seems to have gone cold, but I'm inclined to agree with Pavel.
If the table doesn't exist, neither does the trigger, and the whole point of
the 'IF EXISTS' variants is to provide the ability to issue DROP
On 2013-10-10 12:54:23 -0400, Andrew Dunstan wrote:
On 09/19/2013 06:12 PM, Pavel Stehule wrote:
2013/9/16 Satoshi Nagayasu sn...@uptime.jp mailto:sn...@uptime.jp
I'm looking at this patch, and I have a question here.
Should DROP TRIGGER IF EXISTS ignore error for
On 10/14/2013 05:44 PM, Andres Freund wrote:
On 2013-10-10 12:54:23 -0400, Andrew Dunstan wrote:
On 09/19/2013 06:12 PM, Pavel Stehule wrote:
2013/9/16 Satoshi Nagayasu sn...@uptime.jp mailto:sn...@uptime.jp
I'm looking at this patch, and I have a question here.
Should DROP
On 2013-10-14 17:59:25 -0400, Andrew Dunstan wrote:
On 10/14/2013 05:44 PM, Andres Freund wrote:
On 2013-10-10 12:54:23 -0400, Andrew Dunstan wrote:
On 09/19/2013 06:12 PM, Pavel Stehule wrote:
2013/9/16 Satoshi Nagayasu sn...@uptime.jp mailto:sn...@uptime.jp
I'm looking at this
Hi,
On 14.10.2013 23:44, Andres Freund wrote:
On 2013-10-10 12:54:23 -0400, Andrew Dunstan wrote:
On 09/19/2013 06:12 PM, Pavel Stehule wrote:
2013/9/16 Satoshi Nagayasu sn...@uptime.jp
mailto:sn...@uptime.jp
I'm looking at this patch, and I have a question here.
Should DROP TRIGGER IF
On 2013-10-15 00:23:15 +0200, Tomas Vondra wrote:
Hi,
On 14.10.2013 23:44, Andres Freund wrote:
On 2013-10-10 12:54:23 -0400, Andrew Dunstan wrote:
On 09/19/2013 06:12 PM, Pavel Stehule wrote:
2013/9/16 Satoshi Nagayasu sn...@uptime.jp
mailto:sn...@uptime.jp
I'm looking at this
On 09/19/2013 06:12 PM, Pavel Stehule wrote:
2013/9/16 Satoshi Nagayasu sn...@uptime.jp mailto:sn...@uptime.jp
I'm looking at this patch, and I have a question here.
Should DROP TRIGGER IF EXISTS ignore error for non-existing trigger
and non-existing table? Or just only
2013/9/16 Satoshi Nagayasu sn...@uptime.jp
(2013/07/06 1:16), Pavel Stehule wrote:
I am sending a patch that removes strict requirements for DROP IF
EXISTS statements. This behave is similar to our ALTER IF EXISTS
behave now.
postgres=# DROP CAST IF EXISTS (sss AS public.casttesttype);
(2013/07/06 1:16), Pavel Stehule wrote:
I am sending a patch that removes strict requirements for DROP IF
EXISTS statements. This behave is similar to our ALTER IF EXISTS
behave now.
postgres=# DROP CAST IF EXISTS (sss AS public.casttesttype);
NOTICE: types sss and public.casttesttype does
On Fri, Jul 5, 2013 at 12:16 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
I am sending a patch that removes strict requirements for DROP IF
EXISTS statements. This behave is similar to our ALTER IF EXISTS
behave now.
+1 for this idea. But this patch should be treated as a separate issue
Yes, I wrote a separate patch for next commitfest.
Dne 10.7.2013 16:54 Josh Kupershmidt schmi...@gmail.com napsal(a):
On Fri, Jul 5, 2013 at 12:16 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I am sending a patch that removes strict requirements for DROP IF
EXISTS statements. This
On Tue, Jul 2, 2013 at 5:39 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/3/8 Josh Kupershmidt schmi...@gmail.com:
On Fri, Mar 8, 2013 at 2:23 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2013/3/8 Josh Kupershmidt schmi...@gmail.com:
Cool. I think it would also be useful to
On Tue, Jul 2, 2013 at 7:47 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
Hello
remastered patch
still there is a issue with dependencies
Several of the issues from my last review [1] seem to still be present
in this patch, such as review notes #1 and #4.
And as discussed previously, I
Hello
I am sending a patch that removes strict requirements for DROP IF
EXISTS statements. This behave is similar to our ALTER IF EXISTS
behave now.
postgres=# DROP CAST IF EXISTS (sss AS public.casttesttype);
NOTICE: types sss and public.casttesttype does not exist, skipping
DROP CAST
Hello
2013/3/8 Josh Kupershmidt schmi...@gmail.com:
On Fri, Mar 8, 2013 at 2:23 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/3/8 Josh Kupershmidt schmi...@gmail.com:
Cool. I think it would also be useful to check that --clean may only
be used with --format=p to avoid any confusion
Hello
2013/3/8 Josh Kupershmidt schmi...@gmail.com:
[Moving to -hackers]
On Sat, Feb 23, 2013 at 2:51 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
so
* --conditional-drops replaced by --if-exists
Thanks for the fixes, I played around with the patch a bit. I was sort
of expecting
Hello
remastered patch
still there is a issue with dependencies
Regards
Pavel Stehule
2013/6/17 Josh Kupershmidt schmi...@gmail.com:
On Fri, Mar 8, 2013 at 11:58 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I'll see - please, stay tuned to 9.4 first commitfest
Hi Pavel,
Just a
2013/6/17 Josh Kupershmidt schmi...@gmail.com:
On Fri, Mar 8, 2013 at 11:58 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I'll see - please, stay tuned to 9.4 first commitfest
Hi Pavel,
Just a reminder, I didn't see this patch in the current commitfest. I
would be happy to spend some
On Fri, Mar 8, 2013 at 11:58 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
I'll see - please, stay tuned to 9.4 first commitfest
Hi Pavel,
Just a reminder, I didn't see this patch in the current commitfest. I
would be happy to spend some more time reviewing if you wish to pursue
the patch.
2013/3/8 Josh Kupershmidt schmi...@gmail.com:
[Moving to -hackers]
On Sat, Feb 23, 2013 at 2:51 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
so
* --conditional-drops replaced by --if-exists
Thanks for the fixes, I played around with the patch a bit. I was sort
of expecting this
On Fri, Mar 8, 2013 at 2:23 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/3/8 Josh Kupershmidt schmi...@gmail.com:
Cool. I think it would also be useful to check that --clean may only
be used with --format=p to avoid any confusion there. (This issue
could be addressed in a separate
2013/3/8 Josh Kupershmidt schmi...@gmail.com:
On Fri, Mar 8, 2013 at 2:23 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/3/8 Josh Kupershmidt schmi...@gmail.com:
Cool. I think it would also be useful to check that --clean may only
be used with --format=p to avoid any confusion there.
[Moving to -hackers]
On Sat, Feb 23, 2013 at 2:51 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
so
* --conditional-drops replaced by --if-exists
Thanks for the fixes, I played around with the patch a bit. I was sort
of expecting this example to work (after setting up the regression
71 matches
Mail list logo
