ALTER VIEW does not sound useful for me.
CREATE OR REPLACE VIEW should create or replace view and only thing that
should be same is the name of the view. It's up to Postgres to invalidate
all plans and up to developer to make sure that all places where his view is
used will stay still working. All
On Thu, Aug 7, 2008 at 11:34 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2008-08-07 at 14:59 +0100, Simon Riggs wrote:
>
>> I'll do a patch. Thanks for your input.
>
> Please review attached patch.
Thank you for your patch!
But, there are two problems in this patch, I think.
> !
> Well, my feeling is that if we are inventing a new feature we ought not
> paint ourselves into a corner by failing to consider what will happen
> when obvious extensions to the feature are attempted. Whether the
> present patch is self-consistent is not the question --- the question
> is do we h
Andrew Gierth <[EMAIL PROTECTED]> writes:
> This is fairly obviously a simple consequence of the lack of plan
> invalidation, it just happens to be more serious than most
Hmm, we plugged the correspoding hole on the SELECT side awhile back,
but it seems that INSERT/UPDATE may need some defenses to
"Robert Haas" <[EMAIL PROTECTED]> writes:
> On Thu, Aug 7, 2008 at 5:26 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Because it sidesteps the problem of tracking which column is supposed to
>> be which. If you try to do it through CREATE OR REPLACE VIEW, you have
>> to either be extremely restrictiv
> "Merlin" == "Merlin Moncure" <[EMAIL PROTECTED]> writes:
Merlin> postgres=# alter table abc alter a type numeric;
Merlin> ALTER TABLE
Merlin> Time: 254.847 ms
Merlin> postgres=# EXECUTE ins_abc;
Merlin> INSERT 0 1
Merlin> Time: 0.452 ms
Merlin> postgres=# select * from abc;
Merlin> E
Forgot to copy my response to this to the list.
On Thu, Aug 7, 2008 at 5:26 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Robert Haas" <[EMAIL PROTECTED]> writes:
>> Although several people have said that they prefer the idea of using
>> ALTER VIEW to make changes to views, no one has really expanded
postgres=# create table abc (a int, b int);
CREATE TABLE
Time: 492.417 ms
postgres=# insert into abc values (1,2);
INSERT 0 1
Time: 16.602 ms
postgres=# prepare ins_abc as insert into abc values(1,2);
PREPARE
Time: 0.248 ms
postgres=# alter table abc alter a type numeric;
ALTER TABLE
Time: 254.847
"Robert Haas" <[EMAIL PROTECTED]> writes:
> Although several people have said that they prefer the idea of using
> ALTER VIEW to make changes to views, no one has really expanded on the
> reasons for their preference.
Because it sidesteps the problem of tracking which column is supposed to
be whic
> I'm not too familiar with the syntax "a AS a(x, y)" but I think it's
> asking that the first two columns of a (whatever they are at the
> moment) be aliased to x and y.
Another possible option would be to introduce a syntax along the lines of
table AS table_alias (column AS column_alias, column
>> I think the only thing we need to agree on is that no future implementation
>> of CREATE OR REPLACE VIEW will ever implicitly rename a column. If we agree
>> on column name as a measure of column identity, then the change I'm
>> proposing is forward-compatible with any other enhancements we may
On Aug 7, 2008, at 13:01, Tom Lane wrote:
+1, although what does the standard say?
AFAICT the standard doesn't have any way to alter the definition of an
existing view at all. It might be worth asking what other systems do,
though --- can you alter a view in Oracle or DB2 or mysql?
Looks li
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
> On Aug 7, 2008, at 08:43, Tom Lane wrote:
>> Maybe the right way is to *not* use CREATE OR REPLACE VIEW, but
>> rather ALTER VIEW ADD COLUMN and so on. Then column identity seems
>> a lot easier to keep track of.
> +1, although what does the standa
> Maybe the right way is to *not* use CREATE OR REPLACE VIEW, but
> rather ALTER VIEW ADD COLUMN and so on. Then column identity seems
> a lot easier to keep track of.
>
I prefere ALTER VIEW too
regards
Pavel Stehule
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
"Robert Haas" <[EMAIL PROTECTED]> writes:
> I think the only thing we need to agree on is that no future implementation
> of CREATE OR REPLACE VIEW will ever implicitly rename a column. If we agree
> on column name as a measure of column identity, then the change I'm
> proposing is forward-compati
>> I was thinking that the ADD COLUMN should specify the new result list
>> entry.
>
> Yeah, that's what I was thinking too. If you needed to change more
> than just the topmost SELECT list, you'd need two steps: an ADD COLUMN
> and then CREATE OR REPLACE VIEW to change the query in some way that
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Andrew Dunstan escribió:
>> Tom Lane wrote:
>>> Maybe the right way is to *not* use CREATE OR REPLACE VIEW, but
>>> rather ALTER VIEW ADD COLUMN and so on. Then column identity seems
>>> a lot easier to keep track of.
>>
>> How would that look? Where w
Andrew Dunstan escribió:
>
>
> Tom Lane wrote:
>> Maybe the right way is to *not* use CREATE OR REPLACE VIEW, but
>> rather ALTER VIEW ADD COLUMN and so on. Then column identity seems
>> a lot easier to keep track of.
>
> How would that look? Where would we put the new query?
I was thinking that
> Hmm, maybe we need to pull off the project to separate logical attribute
> number from physical and position. It sounds like it could make it
> easier for view modification.
Much easier! It would be a nice feature to have for table as well.
Right now, if you have a table with columns (foo1, fo
Tom Lane wrote:
Maybe the right way is to *not* use CREATE OR REPLACE VIEW, but
rather ALTER VIEW ADD COLUMN and so on. Then column identity seems
a lot easier to keep track of.
How would that look? Where would we put the new query?
cheers
andrew
--
Sent via pgsql-hackers mailing lis
> But it seems hard to tell the difference between a "rename" and a
> "drop". I think that we aren't going to get far on this until we
> decide what we will consider to be the identity of a view column.
> With regular tables the attnum is a persistent identifier, but that
> doesn't seem to play ni
On Aug 7, 2008, at 08:43, Tom Lane wrote:
Maybe the right way is to *not* use CREATE OR REPLACE VIEW, but
rather ALTER VIEW ADD COLUMN and so on. Then column identity seems
a lot easier to keep track of.
+1, although what does the standard say?
Best,
David
--
Sent via pgsql-hackers mailing
It would make PostgreSQL too much like Oracle ;) Let's keep PostgreSQL
simple and compact please.
I prefer applications retest when migrating to new PostgreSQL version. In
this case surprises happen then you expect them not in some unforeseen point
of time in the future.
Keeping all this old functi
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>
>> I think Simon's interface was overly complex but if we can simplify it then
>> it
>> could be useful. As Grittner mentioned implicit queries could make use of it
>> automatically. Also pg_dump or Slony could make use of it a
On Thu, 2008-08-07 at 10:28 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I propose creating "Visibility Groups" that *explicitly* limit the
> > ability of a transaction to access data outside its visibility group(s).
> > By default, visibility_groups would be NULL, implying
On Thu, 2008-08-07 at 10:56 -0400, Alvaro Herrera wrote:
> Simon Riggs wrote:
> > ii) have postmaster allow connections while Redo is taking place, as
> one
> > part of allowing query access to standby database
>
> is interesting and I'm sure it would be very welcome. Of course, it
> is first n
Tom Lane escribió:
> But it seems hard to tell the difference between a "rename" and a
> "drop". I think that we aren't going to get far on this until we
> decide what we will consider to be the identity of a view column.
> With regular tables the attnum is a persistent identifier, but that
> doe
On Thu, 2008-08-07 at 10:56 -0400, Alvaro Herrera wrote:
> > * have startup process signal postmaster again when it has completed
> > recovery, so that the change of state is via explicit signal rather than
> > death of the child process
>
> I'm not sure that this is very useful, because the sta
Magnus,
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
> I thought of another issue with this. My "grand plan" includes being
> able to do username mapping (per pg_ident.conf) for other authentication
> methods than ident. Specifically this would be interesting for all
> external methods, like gssap
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Robert Haas escribió:
>> Here's a patch that allows CREATE OR REPLACE VIEW to add new columns
>> to an existing view.
> What happens with the columns previously defined? What happens if I
> specify a different column definition for them; does it raise
On Thu, Aug 7, 2008 at 11:17 AM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> Robert Haas escribió:
>> Here's a patch that allows CREATE OR REPLACE VIEW to add new columns
>> to an existing view.
>>
>> Any feedback would be appreciated, especially if it meant that I could
>> fix any problems before
Magnus Hagander wrote:
Simon Riggs wrote:
Not foolproof, but still worth it. This would allow many users to
upgrade to 8.4 for new features, yet without changing apps.
Won't there normally be a number of changes that *cannot* be covered by
such a parameter, without a whole lot more work in th
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Simon Riggs wrote:
>> What I would like is a parameter called sql_compatibility which has
>> settings such as 8.3, 8.4 etc.. By default it would have the value 8.4,
>> but for people that want to upgrade *without* retesting their
>> application, they co
On Thu, 2008-08-07 at 10:48 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I propose to
> > * have startup process signal postmaster when it starts Redo phase (if
> > it starts it)
>
> Doesn't seem like "starts recovery" is the point at which you can start
> letting clients
Robert Haas escribió:
> Here's a patch that allows CREATE OR REPLACE VIEW to add new columns
> to an existing view.
>
> Any feedback would be appreciated, especially if it meant that I could
> fix any problems before the next commitfest.
What happens with the columns previously defined? What hap
Gregory Stark wrote:
> I think Simon's interface was overly complex but if we can simplify it then it
> could be useful. As Grittner mentioned implicit queries could make use of it
> automatically. Also pg_dump or Slony could make use of it automatically.
Hmm, what use would it have for pg_dump?
"Gregory Stark" <[EMAIL PROTECTED]> writes:
> I think Simon's interface was overly complex but if we can simplify it then it
> could be useful. As Grittner mentioned implicit queries could make use of it
> automatically. Also pg_dump or Slony could make use of it automatically.
Sorry "implicit t
Simon Riggs wrote:
> I propose to
> * have startup process signal postmaster when it starts Redo phase (if
> it starts it)
I think the first is a good idea -- at least, if you can get the startup
process to use the normal ReadBuffer code path instead of
XLogReadBuffer. I don't really know what's
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>> I propose creating "Visibility Groups" that *explicitly* limit the
>> ability of a transaction to access data outside its visibility group(s).
>> By default, visibility_groups would be NULL, implying potential acce
> I think this would be a lot of mechanism and complication that will go
> completely unused in the field. It'll be impossible even to explain let
> alone to use effectively, for anyone who's not intensely steeped in the
> details of MVCC.
+1.
This proposal sounds like it would target batch jobs
Simon Riggs <[EMAIL PROTECTED]> writes:
> I propose to
> * have startup process signal postmaster when it starts Redo phase (if
> it starts it)
Doesn't seem like "starts recovery" is the point at which you can start
letting clients into the DB. What you want is to reach a point at which
you're su
Simon Riggs <[EMAIL PROTECTED]> writes:
> I propose creating "Visibility Groups" that *explicitly* limit the
> ability of a transaction to access data outside its visibility group(s).
> By default, visibility_groups would be NULL, implying potential access
> to all tables.
I think this would be a
On Thu, 2008-08-07 at 10:20 -0400, Alvaro Herrera wrote:
> Simon Riggs wrote:
> >
> > Currently, we calculate a single OldestXmin across all snapshots on the
> > assumption that any transaction might access any table.
> >
> > I propose creating "Visibility Groups" that *explicitly* limit the
> >
On Thu, 2008-08-07 at 14:59 +0100, Simon Riggs wrote:
> I'll do a patch. Thanks for your input.
Please review attached patch.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
Index: src/backend/access/transam/xlog.c
==
Simon Riggs wrote:
> What I would like is a parameter called sql_compatibility which has
> settings such as 8.3, 8.4 etc.. By default it would have the value 8.4,
> but for people that want to upgrade *without* retesting their
> application, they could set it to 8.3.
I think down this route lies
Simon Riggs wrote:
>
> Currently, we calculate a single OldestXmin across all snapshots on the
> assumption that any transaction might access any table.
>
> I propose creating "Visibility Groups" that *explicitly* limit the
> ability of a transaction to access data outside its visibility group(s)
Simon Riggs wrote:
On Thu, 2008-08-07 at 14:18 +0100, Richard Huxton wrote:
An attempt to write to user_emails by T0 will fail with an error.
All above correct
The point of doing this is that *if* T0 becomes the oldest transaction
it will *not* interfere with removal of rows on "user_emails"
Simon Riggs wrote:
> Tom's recent changes to allow hash distinct (yay!) prompted something
> that I'd thought about previously.
>
> Subtle changes in the output of queries can force an application retest,
> which then can slow down or prevent an upgrade to the latest release. We
> always assume th
>>> Simon Riggs wrote:
> Currently, we calculate a single OldestXmin across all snapshots on
the
> assumption that any transaction might access any table.
>
> I propose creating "Visibility Groups" that *explicitly* limit the
> ability of a transaction to access data outside its visibility
grou
Tom's recent changes to allow hash distinct (yay!) prompted something
that I'd thought about previously.
Subtle changes in the output of queries can force an application retest,
which then can slow down or prevent an upgrade to the latest release. We
always assume the upgrade itself is the problem
Currently dblink allows regular users to initiate libpq connection
to user-provided connection string. This breaks the default
policy that normal users should not be allowed to freely interact
with outside environment.
In addition to breaking standard security policy, dblink exposes
.pgpass/pg_se
On Thu, 2008-08-07 at 21:11 +0900, Fujii Masao wrote:
> In HEAD, pg_stop_backup waits until the history file has been archived.
> But, in order to ensure that the last wal file was archived, pg_stop_backup
> should wait until not only the history file but also the backup stopping wal
> file has b
On Thu, 2008-08-07 at 14:18 +0100, Richard Huxton wrote:
> Simon Riggs wrote:
> > On Thu, 2008-08-07 at 12:55 +0200, Jochem van Dieten wrote:
> >> On Thu, Aug 7, 2008 at 12:38 PM, Simon Riggs wrote:
> >>> I propose creating "Visibility Groups" that *explicitly* limit the
> >>> ability of a transac
On Thu, 2008-08-07 at 13:30 +0100, Gregory Stark wrote:
> Hm, so backing up a bit from the specific proposed interface, the key here is
> being able to explicitly mark which tables your transaction will need in the
> future?
Think of it as a promise to touch nothing except a specific set of
tabl
Simon Riggs wrote:
On Thu, 2008-08-07 at 12:55 +0200, Jochem van Dieten wrote:
On Thu, Aug 7, 2008 at 12:38 PM, Simon Riggs wrote:
I propose creating "Visibility Groups" that *explicitly* limit the
ability of a transaction to access data outside its visibility group(s).
Doesn't every transacti
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Currently, we calculate a single OldestXmin across all snapshots on the
> assumption that any transaction might access any table.
>
> I propose creating "Visibility Groups" that *explicitly* limit the
> ability of a transaction to access data outside its
Hi
In HEAD, pg_stop_backup waits until the history file has been archived.
But, in order to ensure that the last wal file was archived, pg_stop_backup
should wait until not only the history file but also the backup stopping wal
file has been archived, I think.
Because the alphabetic order of the
Here's a patch that allows CREATE OR REPLACE VIEW to add new columns
to an existing view.
Any feedback would be appreciated, especially if it meant that I could
fix any problems before the next commitfest.
Thanks,
...Robert
Index: doc/src/sgml/ref/create_view.sgml
===
On Thu, 2008-08-07 at 12:55 +0200, Jochem van Dieten wrote:
> On Thu, Aug 7, 2008 at 12:38 PM, Simon Riggs wrote:
> > I propose creating "Visibility Groups" that *explicitly* limit the
> > ability of a transaction to access data outside its visibility group(s).
>
> Doesn't every transaction need
I would like to propose some changes to the infrastructure for recovery.
These changes are beneficial in themselves, but also form the basis for
other work we might later contemplate.
Currently
* the startup process performs restartpoints during recovery
* the death of the startup process is tied
On Thu, Aug 7, 2008 at 12:38 PM, Simon Riggs wrote:
> I propose creating "Visibility Groups" that *explicitly* limit the
> ability of a transaction to access data outside its visibility group(s).
Doesn't every transaction need to access data from the catalogs?
Wouldn't the inclusion of a catalogs
Currently, we calculate a single OldestXmin across all snapshots on the
assumption that any transaction might access any table.
I propose creating "Visibility Groups" that *explicitly* limit the
ability of a transaction to access data outside its visibility group(s).
By default, visibility_groups
Stephen Frost wrote:
> * Magnus Hagander ([EMAIL PROTECTED]) wrote:
>> Tom Lane wrote:
>>> It isn't, and I seem to recall we've had that scenario play out a couple
>>> times already for postgresql.conf changes. But pg_hba.conf is far more
>>> complex than "variable = value" ...
>> Ok, then I didn'
> > Changing statement result type is also currently prohibited in
> > StorePreparedStatement. There maybe good reasons for this,
>
> How about "the SQL spec says so"?
Prepare time is often also the time when you bind the result, or more
generally set up the code to handle the result.
Generally
I just noticed, to my dismay, that has_table_privilege() does not allow
me to check for usage privileges on sequences. I suspect this may have
been an oversight. If so, the attached patch fixes it for me.
-- ams
*** a/src/backend/utils/adt/acl.c
--- b/src/backend/utils/adt/acl.c
***
**
65 matches
Mail list logo
