Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
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
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.
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 pete...@gmx.net 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 grant
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
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
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:
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
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 for
Simon Riggs si...@2ndquadrant.com 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
Gregory Stark st...@enterprisedb.com writes:
Simon Riggs si...@2ndquadrant.com 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
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,
Peter Eisentraut pete...@gmx.net 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
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
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
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);
CREATE TABLE
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
Peter Eisentraut pete...@gmx.net 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
On Wed, Jan 07, 2009 at 11:17:46AM -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
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.
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 other
words,
Bruce Momjian br...@momjian.us 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.
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
Bruce Momjian br...@momjian.us 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
On Tue, Dec 30, 2008 at 11:50:06AM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us 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,
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
you've
On Tue, Dec 30, 2008 at 2:00 PM, David Fetter da...@fetter.org 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
On Tue, Dec 30, 2008 at 04:07:33PM -0500, Jaime Casanova wrote:
On Tue, Dec 30, 2008 at 2:00 PM, David Fetter da...@fetter.org 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
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
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
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 for
David Fetter da...@fetter.org 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
On Sun, Dec 21, 2008 at 11:06:09PM -0500, Tom Lane wrote:
David Fetter da...@fetter.org 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
34 matches
Mail list logo
