Andrew Dunstan wrote:
The pg_dump output was never backward compatible. (The input is.) So
the output of parallel restore need not be backward compatible either.
(Unless this mandate has changed dramatically while I was not
looking?) So always issue TRUNCATE ONLY, if that is what the logic
Peter Eisentraut wrote:
Andrew Dunstan wrote:
It's just occurred to me that if TRUNCATE no longer means TRUNCATE ONLY,
parallel restore will need to detect which server version is being
used so that for version > 8.3 it issues TRUNCATE ONLY.
The pg_dump output was never backward compatible.
Tom Lane wrote:
Peter Eisentraut writes:
The SQL standard uses a recursive-by-default language. For example, the
rules for the DELETE command state:
Actually, I'm not convinced. Take a look at the SELECT WITH HIERARCHY
OPTION stuff in SQL99 and later, in particular this from SQL99
12.2 :
Andrew Dunstan wrote:
It's just occurred to me that if TRUNCATE no longer means TRUNCATE ONLY,
parallel restore will need to detect which server version is being used
so that for version > 8.3 it issues TRUNCATE ONLY.
The pg_dump output was never backward compatible. (The input is.) So
the
Tom Lane wrote:
Peter Eisentraut writes:
The SQL standard uses a recursive-by-default language. For example, the
rules for the DELETE command state:
Actually, I'm not convinced. Take a look at the SELECT WITH HIERARCHY
OPTION stuff in SQL99 and later, in particular this from SQL99
Peter Eisentraut writes:
> The SQL standard uses a recursive-by-default language. For example, the
> rules for the DELETE command state:
Actually, I'm not convinced. Take a look at the SELECT WITH HIERARCHY
OPTION stuff in SQL99 and later, in particular this from SQL99
12.2 :
7) Let
Gregory Stark writes:
> Simon Riggs writes:
>> Please could we put in a GUC to allow that to be toggled in this release
> That seems like it would just be putting off the pain.
Yes, we already had exactly this discussion and concluded that a GUC
wasn't going to improve matters.
Simon Riggs writes:
> On Mon, 2009-01-12 at 11:43 +0200, Peter Eisentraut wrote:
>> Peter Eisentraut wrote:
>> > Tom Lane wrote:
>> >> +1 for making TRUNCATE and LOCK support ONLY.
>> >
>> > Patch attached.
>>
>> This was committed.
>
> Please could we put in a GUC to allow that to be toggled i
On Mon, 2009-01-12 at 11:43 +0200, Peter Eisentraut wrote:
> Peter Eisentraut wrote:
> > Tom Lane wrote:
> >> +1 for making TRUNCATE and LOCK support ONLY.
> >
> > Patch attached.
>
> This was committed.
Please could we put in a GUC to allow that to be toggled in this release
and warning issued
Tom Lane wrote:
Peter Eisentraut writes:
This area is under SQL standard control, so we can't really invent our
own behavior.
What *would* do the right thing here, or would anything?
I think we don't need GRANT to be recursive, but instead the permission
checks at runtime should allow
S
I wrote:
Here is the current line-up:
command supports ONLY
ALTER TABLE all other actions yes
ALTER TABLE RENAME COLUMN yes
ALTER TABLE RENAME no
ALTER TABLE SET SCHEMA documented no, but accepted and ignored
This is actually a bit worse:
Peter Eisentraut wrote:
Tom Lane wrote:
+1 for making TRUNCATE and LOCK support ONLY.
Patch attached.
This was committed.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Eisentraut writes:
>>> This area is under SQL standard control, so we can't really invent our
>>> own behavior.
>> What *would* do the right thing here, or would anything?
> I think we don't need GRANT to be recursive, but instead the permission
> checks at runtime should allow
> SELECT
David Fetter wrote:
On Thu, Jan 08, 2009 at 02:39:52PM +0200, Peter Eisentraut wrote:
David Fetter wrote:
+1 for adding recursion to GRANT/REVOKE :)
This area is under SQL standard control, so we can't really invent our
own behavior.
Consider the following:
CREATE TABLE persons (name, emai
On Thu, Jan 08, 2009 at 02:39:52PM +0200, Peter Eisentraut wrote:
> David Fetter wrote:
>> +1 for adding recursion to GRANT/REVOKE :)
>
> This area is under SQL standard control, so we can't really invent our
> own behavior.
>
> Consider the following:
>
> CREATE TABLE persons (name, email);
> CR
Tom Lane wrote:
+1 for making TRUNCATE and LOCK support ONLY.
Patch attached.
I don't care much about
ALTER TABLE SET SCHEMA, but perhaps there's a use-case for recursion
on that.
I have added this to the Todo list for later reconsideration.
Index: doc/src/sgml/ref/lock.sgml
==
David Fetter wrote:
+1 for adding recursion to GRANT/REVOKE :)
This area is under SQL standard control, so we can't really invent our
own behavior.
Consider the following:
CREATE TABLE persons (name, email);
CREATE TABLE employees (grade, salary) INHERITS (persons);
GRANT SELECT ON persons
On Wed, Jan 07, 2009 at 11:17:46AM -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > [ good summary ]
>
> +1 for making TRUNCATE and LOCK support ONLY. I don't care much
> about ALTER TABLE SET SCHEMA, but perhaps there's a use-case for
> recursion on that. We should stay away from recursiv
Peter Eisentraut writes:
> [ good summary ]
+1 for making TRUNCATE and LOCK support ONLY. I don't care much about
ALTER TABLE SET SCHEMA, but perhaps there's a use-case for recursion
on that. We should stay away from recursive CREATE INDEX for the
moment --- for one thing, you'd have to invent
Tom Lane wrote:
I note though that we have a lot of other non-recursive maintenance
operations (CLUSTER, some variants of ALTER TABLE, etc) ... are we
going to try to make them all recursive?
Here is the current line-up:
command supports ONLY
ALTER TABLE all other acti
On Tue, Dec 30, 2008 at 04:07:33PM -0500, Jaime Casanova wrote:
> On Tue, Dec 30, 2008 at 2:00 PM, David Fetter wrote:
> > Here's one such use-case. Let's say a table has gotten large and
> > you've decided to partition it. You add child tables, add one or
> > more triggers to the parent table t
On Tue, Dec 30, 2008 at 2:00 PM, David Fetter wrote:
>
> Here's one such use-case. Let's say a table has gotten large and
> you've decided to partition it. You add child tables, add one or more
> triggers to the parent table to make sure it never gets a row,
> populate the child tables from the
David Fetter wrote:
> > My vote is to just go ahead and change it. I don't really see much
> > of a use-case for truncating only the parent of an inheritance
> > hierarchy anyway, so I doubt that many people would be affected.
>
> Here's one such use-case. Let's say a table has gotten large and
On Tue, Dec 30, 2008 at 11:50:06AM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Peter Eisentraut wrote:
> >> Considering that TRUNCATE is a pretty dangerous operation, how can we
> >> make adjustments to the behavior without upsetting lots of users?
>
> > Well, it is one of those, "Either
Bruce Momjian writes:
> Tom Lane wrote:
>> My vote is to just go ahead and change it. I don't really see much
>> of a use-case for truncating only the parent of an inheritance
>> hierarchy anyway, so I doubt that many people would be affected.
agreed.
>> I note though that we have a lot of oth
Tom Lane wrote:
> Bruce Momjian writes:
> > Peter Eisentraut wrote:
> >> Considering that TRUNCATE is a pretty dangerous operation, how can we
> >> make adjustments to the behavior without upsetting lots of users?
>
> > Well, it is one of those, "Either we fix it or live with the
> > inconsisten
Bruce Momjian writes:
> Peter Eisentraut wrote:
>> Considering that TRUNCATE is a pretty dangerous operation, how can we
>> make adjustments to the behavior without upsetting lots of users?
> Well, it is one of those, "Either we fix it or live with the
> inconsistency forever". Historically we
Peter Eisentraut wrote:
> Peter Eisentraut wrote:
> > On Monday 22 December 2008 05:09:54 Jaime Casanova wrote:
> >> just out of curiosity, why TRUNCATE doesn't support ONLY?
> >
> > It was probably just an omission.
> >
> > Note that TRUNCATE currently does not act on inheriting tables. In othe
Peter Eisentraut wrote:
On Monday 22 December 2008 05:09:54 Jaime Casanova wrote:
just out of curiosity, why TRUNCATE doesn't support ONLY?
It was probably just an omission.
Note that TRUNCATE currently does not act on inheriting tables. In other
words, the behavior is already like ONLY.
On Monday 22 December 2008 05:09:54 Jaime Casanova wrote:
> just out of curiosity, why TRUNCATE doesn't support ONLY?
It was probably just an omission.
Note that TRUNCATE currently does not act on inheriting tables. In other
words, the behavior is already like ONLY.
FWIW, the SQL standard says
On Sun, Dec 21, 2008 at 11:06:09PM -0500, Tom Lane wrote:
> David Fetter writes:
> > Given that the main (and only sane, IMHO) use for table inheritance is
> > in table partitioning, can we see about deprecating ONLY (in the table
> > inheritance sense) for the next couple of development cycles an
David Fetter writes:
> Given that the main (and only sane, IMHO) use for table inheritance is
> in table partitioning, can we see about deprecating ONLY (in the table
> inheritance sense) for the next couple of development cycles and then
> removing it?
No.
1. It's required by SQL standard.
2.
On Sun, Dec 21, 2008 at 10:09:54PM -0500, Jaime Casanova wrote:
> Hi,
>
> just out of curiosity, why TRUNCATE doesn't support ONLY?
>
> audit=# TRUNCATE only postgres_log;
> ERROR: syntax error at or near "only"
> LINE 1: TRUNCATE only postgres_log;
Given that the main (and only sane, IMHO) use
Hi,
just out of curiosity, why TRUNCATE doesn't support ONLY?
audit=# TRUNCATE only postgres_log;
ERROR: syntax error at or near "only"
LINE 1: TRUNCATE only postgres_log;
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
AsesorÃa y desarrollo de sistemas
Guayaquil - Ecuador
34 matches
Mail list logo
