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
***
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
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't misunderstand
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
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
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
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 to
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
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
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
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
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
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 transaction to access
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 been
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
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
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).
By
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 the
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:
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
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
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
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
ability of a
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 lot of
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 sure
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,
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 access
to all
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
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
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?
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 happens
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 into the DB.
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 could set it
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
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 the next
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 an
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
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 startup
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
doesn't
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 necessary
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 potential
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 automatically.
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
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
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 nicely for
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
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,
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 the ADD
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 would we put the
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
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-compatible
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
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 standard say?
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
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 want to
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 AS
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 which. If
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
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 on the
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 ERROR: invalid
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 restrictive (like
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 too.
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 have
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.
! * Wait
64 matches
Mail list logo
