On 2016-08-05 16:44:20 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-08-05 16:35:02 -0400, Tom Lane wrote:
> >> In particular, it seems to me that rather than implement just this,
> >> we really ought to provide an API that lets FDWs actually implement
> >> TRUNCATE if they feel like
Andres Freund writes:
> On 2016-08-05 16:35:02 -0400, Tom Lane wrote:
>> In particular, it seems to me that rather than implement just this,
>> we really ought to provide an API that lets FDWs actually implement
>> TRUNCATE if they feel like it. Having the trigger and not TRUNCATE
>> capability i
On 2016-08-05 16:35:02 -0400, Tom Lane wrote:
> In particular, it seems to me that rather than implement just this,
> we really ought to provide an API that lets FDWs actually implement
> TRUNCATE if they feel like it. Having the trigger and not TRUNCATE
> capability itself just screams "half bake
Andres Freund writes:
> On 2016-08-05 14:05:02 -0400, Robert Haas wrote:
>> I agree, but I still think it's weird if foreign tables support
>> TRUNCATE itself not but triggers on TRUNCATE.
> You mean the other way round? To me this seems very comparable to
> INSTEAD triggers, but ...
While I ha
On 2016-08-05 14:05:02 -0400, Robert Haas wrote:
> On Fri, Aug 5, 2016 at 2:04 PM, Andres Freund wrote:
> > On 2016-08-05 13:32:18 -0400, Robert Haas wrote:
> >> I think if we're going to add support utility commands on foreign
> >> tables, we ought to think about all of the different utility comm
On Fri, Aug 5, 2016 at 2:04 PM, Andres Freund wrote:
> On 2016-08-05 13:32:18 -0400, Robert Haas wrote:
>> I think if we're going to add support utility commands on foreign
>> tables, we ought to think about all of the different utility commands
>> that someone might want and what exactly we want
On 2016-08-05 13:32:18 -0400, Robert Haas wrote:
> I think if we're going to add support utility commands on foreign
> tables, we ought to think about all of the different utility commands
> that someone might want and what exactly we want the behavior to be.
> For example, consider CLUSTER or CRE
On Fri, Aug 5, 2016 at 10:39 AM, Andres Freund wrote:
> On 2016-08-05 10:33:49 -0400, Tom Lane wrote:
>> Murat Tuncer writes:
>> > I recently hit a road blocker when I tried to create a truncate trigger on
>> > a foreign table. trigger.c::CreateTrigger() function has explicit check to
>> > block
On 2016-08-05 10:33:49 -0400, Tom Lane wrote:
> Murat Tuncer writes:
> > I recently hit a road blocker when I tried to create a truncate trigger on
> > a foreign table. trigger.c::CreateTrigger() function has explicit check to
> > block truncate trigger on foreign tables.
>
> That's good, because
Murat Tuncer writes:
> I recently hit a road blocker when I tried to create a truncate trigger on
> a foreign table. trigger.c::CreateTrigger() function has explicit check to
> block truncate trigger on foreign tables.
That's good, because we don't implement TRUNCATE on foreign tables: there
is n
Hello
I recently hit a road blocker when I tried to create a truncate trigger on
a foreign table. trigger.c::CreateTrigger() function has explicit check to
block truncate trigger on foreign tables.
However, trigger.c::ExecuteTruncate() does not seem to have any problems
issuing before/after trigg
On 12 November 2012 16:22, Robert Haas wrote:
> But I guess that raises the question - should COPY (FREEZE) silently
> ignore the option for not-new relfilenodes, or should it error out?
> Simon proposed the former, but I'm wondering if the latter would be
> better.
It's got some complex pre-con
On Mon, Nov 12, 2012 at 11:20 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Nov 9, 2012 at 3:31 PM, Simon Riggs wrote:
>>> So what we're talking about here is a new mode for COPY, that when
>>> requested will pre-freeze tuples when loading into a newly
>>> created/truncated table. If the
Robert Haas writes:
> On Fri, Nov 9, 2012 at 3:31 PM, Simon Riggs wrote:
>> So what we're talking about here is a new mode for COPY, that when
>> requested will pre-freeze tuples when loading into a newly
>> created/truncated table. If the table isn't newly created/truncated
>> then we'll just ig
On Fri, Nov 9, 2012 at 3:31 PM, Simon Riggs wrote:
> So what we're talking about here is a new mode for COPY, that when
> requested will pre-freeze tuples when loading into a newly
> created/truncated table. If the table isn't newly created/truncated
> then we'll just ignore it and continue. I see
On 9 November 2012 16:27, Tom Lane wrote:
> Simon Riggs writes:
>> On 9 November 2012 15:34, Kevin Grittner wrote:
>>> If we're not talking about making conflicts with other transactions
>>> behave just the same as an unqualified DELETE from a user
>>> perspective, I'm not sure what the goal is,
Robert Haas writes:
> Just having an option to preload frozen tuples dodges all of these
> issues by throwing our hands up in the air, but it does have the
> advantage of being more general. Even if we do that I'm not sure it
> would be a bad thing to try to solve this issue in a somewhat more
>
On Fri, Nov 9, 2012 at 11:27 AM, Tom Lane wrote:
>> My goal is to allow COPY to load frozen tuples without causing MVCC
>> violations.
>
> If that's the goal, I question why you're insisting on touching
> TRUNCATE's behavior. We already have the principle that "TRUNCATE is
> like DELETE except n
On Fri, Nov 9, 2012 at 9:22 AM, Kevin Grittner wrote:
> (1) Any attempt to read from the truncated table would not block. The
> pg_class version included in the transaction's snapshot would
> determine which heap and indexes were accessed.
Well, the thing is, you can't actually do this. When the
Simon Riggs writes:
> On 9 November 2012 15:34, Kevin Grittner wrote:
>> If we're not talking about making conflicts with other transactions
>> behave just the same as an unqualified DELETE from a user
>> perspective, I'm not sure what the goal is, exactly.
> Reasonable question.
> My goal is t
Simon Riggs wrote:
> My goal is to allow COPY to load frozen tuples without causing MVCC
> violations.
OK. That wasn't initially clear to me.
> Forcing a tightly scoped proposal into a much wider one will just
> kill this and leave it blocked.
The goal is important enough and narrow enough to m
Simon Riggs wrote:
>> This seems like a subset of the issues which one might want to
>> address by making DDL statement behave in a more strictly MVCC
>> fashion. Does it make sense to pick those off one at a time, or
>> should something like this be done only in the context of an
>> overall plan
On 9 November 2012 15:46, Simon Riggs wrote:
> Altering TRUNCATE so it behaves perfectly from an MVCC/Serializable
> perspective is a much bigger, and completely different goal, as well
> as something I don't see as desirable anyway for at least 2 good
> reasons, as explained. IMHO if people want
On 9 November 2012 15:34, Kevin Grittner wrote:
> If we're not talking about making conflicts with other transactions
> behave just the same as an unqualified DELETE from a user
> perspective, I'm not sure what the goal is, exactly.
Reasonable question.
My goal is to allow COPY to load frozen t
Merlin Moncure wrote:
> Kevin Grittner wrote:
>> Robert Haas wrote:
>> It seems to me that the goal would be to make this semantically
>> idential to the behavior users would see if an unqualified DELETE
>> were run against the table rather than a TRUNCATE.
>
> but, triggers would not fire, righ
On Fri, Nov 9, 2012 at 8:22 AM, Kevin Grittner wrote:
> Robert Haas wrote:
>
>> What I've been wondering since this last came up is whether we
>> could use some variant of the SIREAD locks Kevin introduced for SSI
>> to handle this case - essentially have the transaction doing the
>> TRUNCATE make
On 9 November 2012 14:22, Kevin Grittner wrote:
> Robert Haas wrote:
>
>> What I've been wondering since this last came up is whether we
>> could use some variant of the SIREAD locks Kevin introduced for SSI
>> to handle this case - essentially have the transaction doing the
>> TRUNCATE make an en
On 9 November 2012 14:55, Marti Raudsepp wrote:
> On Fri, Nov 9, 2012 at 4:24 PM, Simon Riggs wrote:
>> We need a fast lookup structure that is expandable to accommodate
>> arbitrary numbers of truncates. Shared hash table, with some form of
>> overflow mechanism.
>
> Surely you only need to reme
Robert Haas wrote:
> What I've been wondering since this last came up is whether we
> could use some variant of the SIREAD locks Kevin introduced for SSI
> to handle this case - essentially have the transaction doing the
> TRUNCATE make an entry in the lock table that will force a
> serialization
On Fri, Nov 9, 2012 at 4:24 PM, Simon Riggs wrote:
> We need a fast lookup structure that is expandable to accommodate
> arbitrary numbers of truncates. Shared hash table, with some form of
> overflow mechanism.
Surely you only need to remember the last completed truncate for each
relation? The l
On 9 November 2012 14:01, Robert Haas wrote:
> I think the question that hasn't really been adequately answered is:
> where and how are we going to track conflicts? Your previous patch
> involved storing an XID in pg_class, but I think we both found that a
> bit grotty - it'd probably need speci
On Fri, Nov 9, 2012 at 8:22 AM, Simon Riggs wrote:
>> Personally I think the behavior should be dictated by the *reader*.
>> The one doing the truncation may not know about the consistency
>> requirements of particular readers. Especially when you do the
>> truncate via pg_restore or some other ge
On 9 November 2012 10:28, Marti Raudsepp wrote:
> On Wed, Nov 7, 2012 at 5:34 PM, Simon Riggs wrote:
>> I was unhappy with changing the behaviour of TRUNCATE, and still am.
>> So the proposal here is to have a specific modifier on TRUNCATE
>> command that makes it MVCC safe by throwing a serializ
On Wed, Nov 7, 2012 at 5:34 PM, Simon Riggs wrote:
> I was unhappy with changing the behaviour of TRUNCATE, and still am.
> So the proposal here is to have a specific modifier on TRUNCATE
> command that makes it MVCC safe by throwing a serialization error.
> That new behaviour should be requestabl
On 11/09/2012 09:34 AM, Simon Riggs wrote:
On 8 November 2012 23:20, Hannu Krosing wrote:
On 11/08/2012 08:51 PM, Simon Riggs wrote:
On 8 November 2012 17:07, Robert Haas wrote:
On Wed, Nov 7, 2012 at 10:34 AM, Simon Riggs
wrote:
For 9.2 we discussed having COPY setting tuples as frozen. V
On 8 November 2012 23:20, Hannu Krosing wrote:
> On 11/08/2012 08:51 PM, Simon Riggs wrote:
>>
>> On 8 November 2012 17:07, Robert Haas wrote:
>>>
>>> On Wed, Nov 7, 2012 at 10:34 AM, Simon Riggs
>>> wrote:
For 9.2 we discussed having COPY setting tuples as frozen. Various
details
On 11/08/2012 08:51 PM, Simon Riggs wrote:
On 8 November 2012 17:07, Robert Haas wrote:
On Wed, Nov 7, 2012 at 10:34 AM, Simon Riggs wrote:
For 9.2 we discussed having COPY setting tuples as frozen. Various
details apply.
Earlier threads:
"RFC: Making TRUNCATE more "MVCC-safe"
"COPY wit
On 8 November 2012 17:07, Robert Haas wrote:
> On Wed, Nov 7, 2012 at 10:34 AM, Simon Riggs wrote:
>> For 9.2 we discussed having COPY setting tuples as frozen. Various
>> details apply.
>> Earlier threads:
>> "RFC: Making TRUNCATE more "MVCC-safe"
>> "COPY with hints, rebirth"
>>
>> I was un
On Wed, Nov 7, 2012 at 10:34 AM, Simon Riggs wrote:
> For 9.2 we discussed having COPY setting tuples as frozen. Various
> details apply.
> Earlier threads:
> "RFC: Making TRUNCATE more "MVCC-safe"
> "COPY with hints, rebirth"
>
> I was unhappy with changing the behaviour of TRUNCATE, and stil
For 9.2 we discussed having COPY setting tuples as frozen. Various
details apply.
Earlier threads:
"RFC: Making TRUNCATE more "MVCC-safe"
"COPY with hints, rebirth"
I was unhappy with changing the behaviour of TRUNCATE, and still am.
So the proposal here is to have a specific modifier on TRUNC
On Tue, Oct 16, 2012 at 2:12 PM, Stafford, David x78061
wrote:
> On Mon, 15 Oct 2012 10:21:18 -0700, Robert Haas wrote:
>> Yeah, I think the functionality that we need is pretty much there
>> already today. What we need to do is to get the syntax to a point
>> where people can write the code the
On Mon, 15 Oct 2012 10:21:18 -0700, Robert Haas wrote:
> Yeah, I think the functionality that we need is pretty much there
> already today. What we need to do is to get the syntax to a point
> where people can write the code they want to write without getting
> tangled up by it.
>
> I think the
On Mon, Oct 15, 2012 at 3:14 PM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>>> if (select 1 from pg_class where relname = 'foo' and
>>> pg_table_is_visible(oid)) then
>>> truncate table foo;
>>> end if;
>>
>> Yeah, I think the functionality that we need is pretty m
Robert Haas writes:
>>WITH target AS (
>>TRUNCATE TABLE t FROM target;
>
> I'm not exactly sure what that is supposed to do, but it doesn't seem
> like an easy-to-use substitute for truncate-if-exists...
Indeed. I'm still a supporter of truncate-if-exists. Still, we're also
talking about
On Mon, Oct 15, 2012 at 3:14 PM, Dimitri Fontaine
wrote:
> What about continuing to extend on that incredibly useful WITH syntax we
> already have:
>
>WITH target AS (
> SELECT oid::regclass AS t
> FROM pg_class c JOIN pg_namespace n ON c.relnamespace = n.oid
>WHERE pg_ta
Robert Haas writes:
>> if (select 1 from pg_class where relname = 'foo' and
>> pg_table_is_visible(oid)) then
>> truncate table foo;
>> end if;
>
> Yeah, I think the functionality that we need is pretty much there
> already today. What we need to do is to get the synta
On Mon, Oct 15, 2012 at 12:53 PM, Christopher Browne wrote:
> The places where *I* care about this are places where performance is
> almost entirely irrelevant to the question.
>
> When I'm writing 'scripts' that are doing this kind of thing, I'm
> doing schema 'surgery', and, within reason, it's
On Mon, Oct 15, 2012 at 11:57 AM, Robert Haas wrote:
> On Mon, Oct 15, 2012 at 10:34 AM, Greg Stark wrote:
>> I'm a bit lost. I would think pl/pgsql is precisely the same as
>> Oracle's pl/sql and MS's T-SQL. I see the complaint you have as a
>> purely implementation detail. I don't think pl/pgsq
On Mon, Oct 15, 2012 at 10:34 AM, Greg Stark wrote:
> I'm a bit lost. I would think pl/pgsql is precisely the same as
> Oracle's pl/sql and MS's T-SQL. I see the complaint you have as a
> purely implementation detail. I don't think pl/pgsql is the best
> implemented part of Postgres but I don't se
On 10/15/2012 04:34 PM, Greg Stark wrote:
On Mon, Oct 15, 2012 at 3:26 PM, Robert Haas wrote:
To be perfectly frank, I think that's exactly where we ought to be
going. Oracle and Microsoft both did it, so why are we convinced it's
a bad idea? One of the huge problems with PL/pgsql is that eve
On Mon, Oct 15, 2012 at 3:26 PM, Robert Haas wrote:
> To be perfectly frank, I think that's exactly where we ought to be
> going. Oracle and Microsoft both did it, so why are we convinced it's
> a bad idea? One of the huge problems with PL/pgsql is that every SQL
> expression in there has to be
On Fri, Oct 12, 2012 at 5:52 PM, Dimitri Fontaine
wrote:
> Christopher Browne writes:
>> I suggest the though of embracing statement modifiers in DDL, with
>> some options possible:
>> a) { DDL STATEMENT } IF CONDITION;
>> b) { DDL STATEMENT } UNLESS CONDITION;
>
> Just saying. I hate that. M
On 10/12/12 3:49 PM, Greg Stark wrote:
> TRUNCATE IF EXISTS foo;
> CREATE IF NOT EXISTS foo...
Thing is, this can be written:
CREATE IF NOT EXISTS foo ...
TRUNCATE foo;
For the exact same result.
So, based on all of the objections and discussion on this feature, I
personally no longer support i
On Tue, Oct 9, 2012 at 9:04 PM, Robert Haas wrote:
> I've been a big proponent of adding "IF EXISTS" support to CREATE
> TABLE and ALTER TABLE but I'm having a hard time getting excited about
> this one. I can't imagine that many people would use it
The reason CREATE IF NOT EXISTS and DROP IF EX
On Fri, Oct 12, 2012 at 5:52 PM, Dimitri Fontaine
wrote:
> Christopher Browne writes:
>> I suggest the though of embracing statement modifiers in DDL, with
>> some options possible:
>> a) { DDL STATEMENT } IF CONDITION;
>> b) { DDL STATEMENT } UNLESS CONDITION;
>
> Just saying. I hate that. M
>> where CONDITION has several possible forms:
>> i) {IF|UNLESS} ( SQL expression returning T/F )
>> ii) {IF|UNLESS} {EXISTS|NOT EXISTS}
>> {TABLE|SCHEMA|COLUMN|FUNCTION|...} object_name
>
> Now we're talking about T-SQL? Sorry, I suppose you didn't mean to lead
> us that way, but I couldn't
Christopher Browne writes:
> I suggest the though of embracing statement modifiers in DDL, with
> some options possible:
> a) { DDL STATEMENT } IF CONDITION;
> b) { DDL STATEMENT } UNLESS CONDITION;
Just saying. I hate that. Makes it harder to read, that last bit at the
end of the command cha
On 10/12/2012 11:05 PM, Christopher Browne wrote:
On Fri, Oct 12, 2012 at 3:04 PM, Robert Haas wrote:
On Thu, Oct 11, 2012 at 3:22 PM, Simon Riggs wrote:
So we just need a function called pg_if_table_exists(table, SQL) which
wraps a test in a subtransaction.
And you write
SELECT pg_if_table
On 10/12/12 2:05 PM, Christopher Browne wrote:
> That feels like a cleaner extension than what we have had, with the IF
> EXISTS/IF NOT EXISTS clauses that have been added to various
> CREATE/DROP/ALTER commands.
+1
Josh like!
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Se
On Fri, Oct 12, 2012 at 3:04 PM, Robert Haas wrote:
> On Thu, Oct 11, 2012 at 3:22 PM, Simon Riggs wrote:
>> So we just need a function called pg_if_table_exists(table, SQL) which
>> wraps a test in a subtransaction.
>>
>> And you write
>>
>> SELECT pg_if_table_exists('foo', 'TRUNCATE TABLE foo')
On Fri, Oct 12, 2012 at 3:23 PM, Alvaro Herrera
wrote:
> Uh, we had an execute() function of sorts in the extensions patch; that
> seems to have been ripped out. Do we want it back?
Well, it wasn't necessary for that patch, which is why it got ripped
out. But I don't remember anybody saying it
Alvaro Herrera writes:
> Uh, we had an execute() function of sorts in the extensions patch; that
> seems to have been ripped out. Do we want it back?
It was pretty different from what's being proposed here, as it was the
server-side version of psql \i feature, that is, executing commands read
di
* Josh Berkus (j...@agliodbs.com) wrote:
> On 10/9/12 1:35 PM, Peter Eisentraut wrote:
> > On 10/9/12 5:09 AM, Simon Riggs wrote:
> >> Anyone want to check for any other missing IF EXISTS capability in other
> >> DDL?
> >
> > TRUNCATE is not really DDL. If we allow TRUNCATE IF EXISTS, what is
>
Robert Haas escribió:
> On Thu, Oct 11, 2012 at 3:22 PM, Simon Riggs wrote:
> > So we just need a function called pg_if_table_exists(table, SQL) which
> > wraps a test in a subtransaction.
> >
> > And you write
> >
> > SELECT pg_if_table_exists('foo', 'TRUNCATE TABLE foo');
> >
> > and we can even
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Second, to my mind the point of a multi-table TRUNCATE is to ensure that
> all the referenced tables get reset to empty *together*. With something
> like this, you'd have no such guarantee. Consider a timeline like this:
Don't we have the exact same issue
* Robert Haas (robertmh...@gmail.com) wrote:
> INSERT IF EXISTS (and, hey, why not INSERT OR
> CREATE for good measure?). I'm not sure what the right thing to do
> is... but we should probably come up with some consensus position we
> can all live with, and then go make this uniform[1].
'INSERT O
On Thu, Oct 11, 2012 at 3:22 PM, Simon Riggs wrote:
> So we just need a function called pg_if_table_exists(table, SQL) which
> wraps a test in a subtransaction.
>
> And you write
>
> SELECT pg_if_table_exists('foo', 'TRUNCATE TABLE foo');
>
> and we can even get rid of all that other DDL crud that
Andrew Dunstan writes:
> This strikes me as just highly un-SQL-like.
+1
> I tend to agree with Noah's comment upthread:
>
>> But the syntax is a bandage for raw psql input remaining a hostile
>> environment for implementing the full range of schema changes. Switch to
>> submitting your SQL from
Hello
2012/10/12 Sébastien Lardière :
> On 10/11/2012 09:22 PM, Simon Riggs wrote:
>
>>>
>>> That is a lot more typing and it's not exactly intuitive. One obvious
>>> thing that would help is a function pg_table_exists(text) that would
>>> return true or false. But even with that there's a lot o
On 10/12/2012 12:03 PM, Sébastien Lardière wrote:
If we can do something like :
SELECT pg_if_table_exists('bar' , pg_if_table_exists('foo', 'TRUNCATE
TABLE foo, bar, foobar')) ;
or
SELECT pg_if_tables_exists('TRUNCATE TABLE foo, bar, foobar', 'foo',
'bar') ;
I say yes !
This strikes m
On 10/11/2012 09:22 PM, Simon Riggs wrote:
>>
>> That is a lot more typing and it's not exactly intuitive. One obvious
>> thing that would help is a function pg_table_exists(text) that would
>> return true or false. But even with that there's a lot of syntactic
>> sugar in there that is less tha
On 11 October 2012 19:59, Robert Haas wrote:
> On Wed, Oct 10, 2012 at 3:32 AM, Simon Riggs wrote:
>> 2) Clearly, rollout scripts benefit from not throwing errors.
>> Personally I would prefer setting SET ddl_abort_on_missing_object =
>> false; at the top of a script than having to go through eve
On Wed, Oct 10, 2012 at 3:32 AM, Simon Riggs wrote:
> 2) Clearly, rollout scripts benefit from not throwing errors.
> Personally I would prefer setting SET ddl_abort_on_missing_object =
> false; at the top of a script than having to go through every SQL
> statement and add extra syntax. That might
> For starters, the use-case hasn't been explained to my satisfaction.
> In what situation is it actually helpful to TRUNCATE a table that's
> not there yet? Aren't you going to have to do a CREATE IF NOT EXISTS
> to keep from failing later in the script? If so, why not just do that
> first?
The
On 10/09/2012 04:06 PM, Tom Lane wrote:
> Second, to my mind the point of a multi-table TRUNCATE is to ensure that
> all the referenced tables get reset to empty *together*. With something
> like this, you'd have no such guarantee. Consider a timeline like this:
>
> Session 1
On 10/09/2012 10:04 PM, Robert Haas wrote:
>> - if a table is not yet or no more visible, because of search_path
>> modification
>
> I don't think I understand the case you are describing here.
Here's a sample :
begin;
set search_path = foo, public;
create table c ( … ) ;
commit;
begin;
set
On 10/9/12 1:35 PM, Peter Eisentraut wrote:
> On 10/9/12 5:09 AM, Simon Riggs wrote:
>> Anyone want to check for any other missing IF EXISTS capability in other DDL?
>
> TRUNCATE is not really DDL. If we allow TRUNCATE IF EXISTS, what is
> stopping someone from requesting DELETE IF EXISTS or INSE
On Wed, Oct 10, 2012 at 3:32 AM, Simon Riggs wrote:
> On 10 October 2012 02:10, Robert Haas wrote:
>> On Tue, Oct 9, 2012 at 4:18 PM, Josh Berkus wrote:
>>> The second is for making deployment scripts idempotent. For example,
>>> say you have script A which creates table "josh", and script B wh
On 10 October 2012 02:10, Robert Haas wrote:
> On Tue, Oct 9, 2012 at 4:18 PM, Josh Berkus wrote:
>> The second is for making deployment scripts idempotent. For example,
>> say you have script A which creates table "josh", and script B which
>> needs table "josh" to be empty, if present. Since
On Tue, Oct 09, 2012 at 09:10:13PM -0400, Robert Haas wrote:
> On Tue, Oct 9, 2012 at 4:18 PM, Josh Berkus wrote:
> > The second is for making deployment scripts idempotent. For example,
> > say you have script A which creates table "josh", and script B which
> > needs table "josh" to be empty, i
Robert Haas writes:
> On Tue, Oct 9, 2012 at 4:18 PM, Josh Berkus wrote:
>> The second is for making deployment scripts idempotent. For example,
>> say you have script A which creates table "josh", and script B which
>> needs table "josh" to be empty, if present. Since the two scripts are
>> ti
On Tue, Oct 9, 2012 at 4:18 PM, Josh Berkus wrote:
> The second is for making deployment scripts idempotent. For example,
> say you have script A which creates table "josh", and script B which
> needs table "josh" to be empty, if present. Since the two scripts are
> tied to different database fe
On Tue, Oct 9, 2012 at 2:04 PM, Simon Riggs wrote:
> On 9 October 2012 21:35, Peter Eisentraut wrote:
>> On 10/9/12 5:09 AM, Simon Riggs wrote:
>>> Anyone want to check for any other missing IF EXISTS capability in other
>>> DDL?
>>
>> TRUNCATE is not really DDL. If we allow TRUNCATE IF EXISTS,
On 9 October 2012 21:35, Peter Eisentraut wrote:
> On 10/9/12 5:09 AM, Simon Riggs wrote:
>> Anyone want to check for any other missing IF EXISTS capability in other DDL?
>
> TRUNCATE is not really DDL. If we allow TRUNCATE IF EXISTS, what is
> stopping someone from requesting DELETE IF EXISTS or
On 10/10/12 09:35, Peter Eisentraut wrote:
On 10/9/12 5:09 AM, Simon Riggs wrote:
Anyone want to check for any other missing IF EXISTS capability in other DDL?
TRUNCATE is not really DDL. If we allow TRUNCATE IF EXISTS, what is
stopping someone from requesting DELETE IF EXISTS or INSERT IF EXI
On 10/9/12 5:09 AM, Simon Riggs wrote:
> Anyone want to check for any other missing IF EXISTS capability in other DDL?
TRUNCATE is not really DDL. If we allow TRUNCATE IF EXISTS, what is
stopping someone from requesting DELETE IF EXISTS or INSERT IF EXISTS next?
--
Sent via pgsql-hackers mail
Robert,
> I've been a big proponent of adding "IF EXISTS" support to CREATE
> TABLE and ALTER TABLE but I'm having a hard time getting excited about
> this one. I can't imagine that many people would use it, and those
> who do can implement it in about 10 lines of PL/pgsql. The existence
> of DO
On 9 October 2012 15:06, Tom Lane wrote:
> Simon Riggs writes:
>> On 9 October 2012 09:33, Sébastien Lardière wrote:
>>> With the help of Cédric, here's a patch changing the TRUNCATE TABLE
>>> command, adding the IF EXISTS option to allow the presence in the list
>>> of tables of a missing or in
On Tue, Oct 9, 2012 at 12:28 PM, Sébastien Lardière
wrote:
>> For starters, the use-case hasn't been explained to my satisfaction.
>> In what situation is it actually helpful to TRUNCATE a table that's
>> not there yet? Aren't you going to have to do a CREATE IF NOT EXISTS
>> to keep from failing
On 10/09/2012 04:06 PM, Tom Lane wrote:
> Simon Riggs writes:
>> On 9 October 2012 09:33, Sébastien Lardière wrote:
>>> With the help of Cédric, here's a patch changing the TRUNCATE TABLE
>>> command, adding the IF EXISTS option to allow the presence in the list
>>> of tables of a missing or invi
=?ISO-8859-1?Q?S=E9bastien_Lardi=E8re?= writes:
> Indeed, brackets was not correct, it's better now (I think), and correct
> some comments.
Still wrong ... at the very least you missed copyfuncs/equalfuncs.
In general, when adding a field to a struct, it's good practice to
grep for all uses of th
Simon Riggs writes:
> On 9 October 2012 09:33, Sébastien Lardière wrote:
>> With the help of Cédric, here's a patch changing the TRUNCATE TABLE
>> command, adding the IF EXISTS option to allow the presence in the list
>> of tables of a missing or invisible table.
> Will apply in 48 hours barring
On Tue, Oct 9, 2012 at 11:51 AM, Vik Reykja wrote:
> On Tue, Oct 9, 2012 at 11:09 AM, Simon Riggs wrote:
>
>> Anyone want to check for any other missing IF EXISTS capability in other
>> DDL?
>>
>
> Yes, DEALLOCATE.
>
Patch attached.
deallocate_if_exists.patch
Description: Binary data
--
Sent
On Tue, Oct 9, 2012 at 11:09 AM, Simon Riggs wrote:
> Anyone want to check for any other missing IF EXISTS capability in other
> DDL?
>
Yes, DEALLOCATE.
On 10/09/2012 11:09 AM, Simon Riggs wrote:
> On 9 October 2012 09:33, Sébastien Lardière wrote:
>
>> With the help of Cédric, here's a patch changing the TRUNCATE TABLE
>> command, adding the IF EXISTS option to allow the presence in the list
>> of tables of a missing or invisible table.
>>
>> Thi
On 9 October 2012 09:33, Sébastien Lardière wrote:
> With the help of Cédric, here's a patch changing the TRUNCATE TABLE
> command, adding the IF EXISTS option to allow the presence in the list
> of tables of a missing or invisible table.
>
> This meets the needs of scripts that should be run in
Hi,
With the help of Cédric, here's a patch changing the TRUNCATE TABLE
command, adding the IF EXISTS option to allow the presence in the list
of tables of a missing or invisible table.
This meets the needs of scripts that should be run in different stages,
and do not always have the same visibil
On Wed, Feb 10, 2010 at 12:19 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Tom Lane wrote:
>>> The code is only trying to substitute for something you can't have
>>> in parallel restore, ie --single-transaction.
>
>> Exactly. IIRC that's why --single-transaction was introduced in the
>> first
2010/2/10 Takahiro Itagaki
>
> Tom Lane wrote:
>
> > Takahiro Itagaki writes:
> > > We have an optimization to bulkload date in pg_restore, but the code
> > > only works in parallel restore (--jobs >= 2). Why don't we do the
> > > same optimization in the serial restore (--jobs = 1) ?
> >
> > T
Andrew Dunstan wrote:
> Takahiro-san is suggesting there is a case for doing the optimisation in
> non-parallel mode. But if we do that, is there still a case for
> --single-transaction?
I think --single-transaction is useful to restore data into non-empty
databases. A normal restore ignores
1 - 100 of 227 matches
Mail list logo
