On 2016/04/06 8:48, David Fetter wrote:
> On Tue, Apr 05, 2016 at 07:10:56PM -0400, Robert Haas wrote:
>> On Tue, Apr 5, 2016 at 6:50 PM, David Fetter wrote:
>>> Is there a reason other than lack of tuits for this restriction?
>>
>> "this" lacks an antecedent.
>
> Try to put a primary key on a ma
On Tue, Apr 05, 2016 at 07:10:56PM -0400, Robert Haas wrote:
> On Tue, Apr 5, 2016 at 6:50 PM, David Fetter wrote:
> > Is there a reason other than lack of tuits for this restriction?
>
> "this" lacks an antecedent.
Try to put a primary key on a materialized view, for example:
CREATE TABLE
On Tue, Apr 5, 2016 at 6:50 PM, David Fetter wrote:
> Is there a reason other than lack of tuits for this restriction?
"this" lacks an antecedent.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
Folks,
Is there a reason other than lack of tuits for this restriction?
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.po
On Wed, Oct 29, 2014 at 1:57 PM, Stephen Frost wrote:
>> No. Materialized views don't have column defaults, and marking them
>> security_barrier does nothing.
>
> I'm a bit confused by this- views have column defaults?
Yep.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterpris
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Oct 29, 2014 at 1:26 PM, Stephen Frost wrote:
> > I agree with this, certainly, but these are not considerations that the
> > SQL spec takes into account. I've always found it odd of the spec to
> > avoid these considerations and concerns, bu
On Wed, Oct 29, 2014 at 1:26 PM, Stephen Frost wrote:
> I agree with this, certainly, but these are not considerations that the
> SQL spec takes into account. I've always found it odd of the spec to
> avoid these considerations and concerns, but it is the spec and it's
> viewpoint that we're disc
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Oct 27, 2014 at 11:45 AM, Stephen Frost wrote:
> > I don't think Kevin was wrong to use a different relkind, but I don't
> > buy into the argument that a different relkind means it's not a view.
> > As for the other comments, I agree that a ma
On Mon, Oct 27, 2014 at 11:45 AM, Stephen Frost wrote:
>> But I think it's the wrong thing anyway, because it presumes that,
>> when Kevin chose to make materialized views a different relkind and a
>> different object type, rather than just a property of an object, he
>> made the wrong call, and I
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Oct 17, 2014 at 8:10 PM, Stephen Frost wrote:
> > * Peter Eisentraut (pete...@gmx.net) wrote:
> >> On 10/16/14 9:45 AM, Stephen Frost wrote:
> >> > Alright, coming back to this, I have to ask- how are matviews different
> >> > from views from
On Fri, Oct 17, 2014 at 8:10 PM, Stephen Frost wrote:
> * Peter Eisentraut (pete...@gmx.net) wrote:
>> On 10/16/14 9:45 AM, Stephen Frost wrote:
>> > Alright, coming back to this, I have to ask- how are matviews different
>> > from views from the SQL standard's perspective? I tried looking throug
> Does someone know what other DBMSs do in this regard? I.e., do they
> put anything in INFORMATION_SCHEMA.VIEWS for matviews? What TABLE_TYPE
> do they use in INFORMATION_SCHEMA.TABLES?
I can only speak for Oracle.
Oracle doesn't have INFORMATION_SCHEMA but their JDBC driver treats mviews
as t
2014-10-18 Stephen Frost :
> * Peter Eisentraut (pete...@gmx.net) wrote:
>
>> More subtly, if we claim that a materialized view is a view, then we
>> cannot have asynchronously updated materialized views, because then we
>> have different semantics.
>
> This is, at least, a reason I can understand
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 10/16/14 9:45 AM, Stephen Frost wrote:
> > Alright, coming back to this, I have to ask- how are matviews different
> > from views from the SQL standard's perspective? I tried looking through
> > the standard to figure it out (and I admit that I prob
* Nicolas Barbier (nicolas.barb...@gmail.com) wrote:
> 2014-10-16 Stephen Frost :
>
> > Alright, coming back to this, I have to ask- how are matviews different
> > from views from the SQL standard's perspective?
>
> Matviews that are always up to date when you access them are
> semantically exact
On 10/17/14, 4:31 AM, David G Johnston wrote:
Since the standard doesn't distinguish between read and write aspects of the
object types there isn't a safe way to add matviews to the information
schema that doesn't violate the intent of the provided view. If the
application/users wants to support
On 10/16/14 9:45 AM, Stephen Frost wrote:
> Alright, coming back to this, I have to ask- how are matviews different
> from views from the SQL standard's perspective? I tried looking through
> the standard to figure it out (and I admit that I probably missed
> something), but the only thing appears
Nicolas Barbier wrote
> 2014-10-16 Stephen Frost <
> sfrost@
> >:
>
>> Alright, coming back to this, I have to ask- how are matviews different
>> from views from the SQL standard's perspective?
>
> Matviews that are always up to date when you access them are
> semantically exactly the same as n
2014-10-16 Stephen Frost :
> Alright, coming back to this, I have to ask- how are matviews different
> from views from the SQL standard's perspective?
Matviews that are always up to date when you access them are
semantically exactly the same as normal views. Matviews that can get
out of date, how
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 10/10/14 8:44 PM, Stephen Frost wrote:
> > As a comparison, what about unlogged tables? They're not normal tables
> > and they aren't defined by the SQL standard either.
>
> They are normal tables when considered within the scope of the SQL
> stand
On 10/10/14 8:44 PM, Stephen Frost wrote:
> As a comparison, what about unlogged tables? They're not normal tables
> and they aren't defined by the SQL standard either.
They are normal tables when considered within the scope of the SQL
standard. The only difference to normal tables is their cras
Another example is an ETL tool or ORM that queries the data dictionary to
generate SQL or object models.
If mviews show up in the regular information_schema views (specifically the
.columns view) then it'll just work as if it's a regular table or view (ex:
like foreign tables).
If not, it's po
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 10/10/14 6:53 PM, Stephen Frost wrote:
> > I'm not particularly thrilled with this answer. I'd aruge that the
> > 'materialized' part of mat views isn't relevant to the standard, which
> > does not concern itself with such performance-oriented consi
On 10/10/14 6:53 PM, Stephen Frost wrote:
> I'm not particularly thrilled with this answer. I'd aruge that the
> 'materialized' part of mat views isn't relevant to the standard, which
> does not concern itself with such performance-oriented considerations,
> and therefore, to the standard's view (
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Sehrope Sarkuni writes:
> > I've been testing out some of the new materialized view functionality
> > in 9.4 and noticed that they don't show up in the information_schema
> > data dictionary views, specifically information_schema.tables or
> > information_s
Sehrope Sarkuni writes:
> I've been testing out some of the new materialized view functionality
> in 9.4 and noticed that they don't show up in the information_schema
> data dictionary views, specifically information_schema.tables or
> information_schema.views (sample output is below and it's the
Hi,
I've been testing out some of the new materialized view functionality
in 9.4 and noticed that they don't show up in the information_schema
data dictionary views, specifically information_schema.tables or
information_schema.views (sample output is below and it's the same for
9.3 as well).
Is t
Kevin Grittner wrote:
> Noah Misch wrote:
>> Also, could you explain the use of RelationCacheInvalidateEntry()
>> in ExecRefreshMatView()? CacheInvalidateRelcacheByRelid()
>> followed by CommandCounterIncrement() is the typical pattern;
>> this is novel. I suspect, though, neither is necessary
Apologies, but this sub-thread got lost when I changed email
accounts. I found it in a final review to make sure nothing had
fallen through the cracks.
Noah Misch wrote:
> On Thu, Jan 24, 2013 at 01:09:28PM -0500, Noah Misch wrote:
>> There's no documented support for table constraints on MVs,
While doing some post-commit review of the 9.3 materialized view feature, I
noticed a few loose ends:
On Thu, Jan 24, 2013 at 01:09:28PM -0500, Noah Misch wrote:
> Note that [...] "ALTER TABLE ... RENAME CONSTRAINT" [is]
> currently supported for MVs by ALTER TABLE but not by ALTER MATERIALIZED VI
The table at
http://www.postgresql.org/docs/devel/static/event-trigger-matrix.html
does not include things like CREATE MATERIALIZED VIEW or REFRESH
MATERIALIZED VIEW. but they certainly seem to work?
Just a missing doc patch, or is there something in the code that's not
behaving as intended?
If
On Thu, Mar 7, 2013 at 12:14 PM, David E. Wheeler wrote:
> On Mar 7, 2013, at 7:55 AM, Kevin Grittner wrote:
>>> If the answer to both those questions is “yes,” I think the term
>>> should remain “table,” with a few mentions that the term includes
>>> materialized views (and excludes foreign tabl
On Tue, Mar 5, 2013 at 08:50:39AM +, Simon Riggs wrote:
> Its not a different feature, its what most people expect a feature
> called MV to deliver. That's not a matter of opinion, its simply how
> every other database works currently - Oracle, Teradata, SQLServer at
> least. The fact that we
On Wed, Mar 6, 2013 at 09:16:59AM -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On 5 March 2013 22:02, Tom Lane wrote:
> >> FWIW, my opinion is that doing anything like this in the planner is
> >> going to be enormously expensive.
>
> > As we already said: no MVs => zero overhead => no probl
On Fri, Mar 8, 2013 at 12:32 PM, Tom Lane wrote:
> Craig Ringer writes:
> > On 03/08/2013 10:55 AM, Michael Paquier wrote:
> >> Also, as it is not mandatory for a unique index to be a constraint, I
> >> think that we should block the creation of unique indexes too to avoid
> >> any problems. Any
Craig Ringer writes:
> On 03/08/2013 10:55 AM, Michael Paquier wrote:
>> Also, as it is not mandatory for a unique index to be a constraint, I
>> think that we should block the creation of unique indexes too to avoid
>> any problems. Any suggestions?
> How much does the planner benefit from the i
On 03/08/2013 10:55 AM, Michael Paquier wrote:
> Also, as it is not mandatory for a unique index to be a constraint, I
> think that we should block the creation of unique indexes too to avoid
> any problems. Any suggestions?
How much does the planner benefit from the implied constraint of a
unique
On Fri, Mar 8, 2013 at 11:33 AM, Josh Berkus wrote:
>
> > As expected, the refresh failed, but the error message is not really
> > user-friendly.
> > Shouldn't we output instead something like that?
> > ERROR: could not refresh materialized view because of failure when
> > rebuilding index"
> > D
> As expected, the refresh failed, but the error message is not really
> user-friendly.
> Shouldn't we output instead something like that?
> ERROR: could not refresh materialized view because of failure when
> rebuilding index"
> DETAIL: key is duplicated.
Is there a good reason to allow unique i
Hi all,
While testing materialized views, I found the following behavior with
unique indexes:
postgres=# create table aa as select generate_series(1,3) as a;
SELECT 3
postgres=# create materialized view aam as select * from aa;
SELECT 3
postgres=# create unique index aam_ind on aam(a);
CREATE INDE
2013/3/5 Kevin Grittner :
> Perhaps it would be worth looking for anything in the patch that
> you think might be painting us into a corner where it would be hard
> to do all the other cool things. While it's late enough in the
> process that changing anything like that which you find would be
>
On Mar 7, 2013, at 7:55 AM, Kevin Grittner wrote:
>> If the answer to both those questions is “yes,” I think the term
>> should remain “table,” with a few mentions that the term includes
>> materialized views (and excludes foreign tables).
>
> And if the answers are "not exactly" and "yes"?
I s
David E. Wheeler wrote:
> Kevin Grittner wrote:
>
>> I also think that something should be done about the
>> documentation for indexes. Right now that always refers to a
>> "table". It would clearly be awkward to change that to "table
>> or materialized view" everywhere. I wonder if most of th
On 6 March 2013 14:16, Tom Lane wrote:
> Simon Riggs writes:
>> On 5 March 2013 22:02, Tom Lane wrote:
>>> FWIW, my opinion is that doing anything like this in the planner is
>>> going to be enormously expensive.
>
>> As we already said: no MVs => zero overhead => no problem.
>
> Well, in the fi
> Kevin Grittner wrote:
>> Tatsuo Ishii wrote:
>>
>>> Was the remaining work on docs done? I would like to test MVs and
>>> am waiting for the docs completed.
>>
>> I think they are done. If you notice anything missing or in need
>> of clarification please let me know. At this point missing doc
On Mar 6, 2013, at 1:51 PM, Kevin Grittner wrote:
> I also think that something should be done about the documentation
> for indexes. Right now that always refers to a "table". It would
> clearly be awkward to change that to "table or materialized view"
> everywhere. I wonder if most of thosse
Kevin Grittner wrote:
> Tatsuo Ishii wrote:
>
>> Was the remaining work on docs done? I would like to test MVs and
>> am waiting for the docs completed.
>
> I think they are done. If you notice anything missing or in need
> of clarification please let me know. At this point missing docs
> would
On Tue, Mar 5, 2013 at 9:08 PM, Robert Haas wrote:
> All that having been said, it's hard for me to imagine that anyone
> really cares about any of this until we have an incremental update
> feature, which right now we don't. Actually, I'm betting that's going
> to be significantly harder than au
Kevin,
I haven't seen a reply to this. Were you able to give my notes below
any consideration?
On 2/15/13 12:44 PM, Peter Eisentraut wrote:
> On 1/25/13 1:00 AM, Kevin Grittner wrote:
>> New patch rebased, fixes issues raised by Thom Brown, and addresses
>> some of your points.
>
> This patch
Tatsuo Ishii wrote:
> Was the remaining work on docs done? I would like to test MVs and
> am waiting for the docs completed.
I think they are done. If you notice anything missing or in need
of clarification please let me know. At this point missing docs
would be a bug in need of a fix.
--
Kev
Simon Riggs writes:
> On 5 March 2013 22:02, Tom Lane wrote:
>> FWIW, my opinion is that doing anything like this in the planner is
>> going to be enormously expensive.
> As we already said: no MVs => zero overhead => no problem.
Well, in the first place that statement is false on its face: we'
On 5 March 2013 22:02, Tom Lane wrote:
> FWIW, my opinion is that doing anything like this in the planner is
> going to be enormously expensive. Index matching is already pretty
> expensive, and that has the saving grace that we only do it once per
> base relation. Your sketch above implies try
> Kevin Grittner wrote:
>
>> REFRESH MATERIALIZED VIEW name [, ...] WITH [ NO ] DATA
>
> Given the short time, I left out the "[, ...]". If people think
> that is important to get into this release, a follow-on patch might
> be possible.
>
>> Barring objections, I will use the above and push t
On 03/05/2013 01:09 PM, Kevin Grittner wrote:
> Josh Berkus wrote:
>
> There is no shortage of literature on the topic, although any
> papers from the ACM could certainly be of interest due to the
> general high quality of papers published there. Adding anything
> like this to 9.3 is clearly out
Nicolas Barbier wrote:
> PS. Sorry for having fired off this discussion that obviously
> doesn’t really relate to the current patch.
I know it's hard to resist. While I think there will be a number
of people for whom the current patch will be a convenience and will
therefore use it, it is hard
2013/3/5 Kevin Grittner :
> Exactly. I predict that we will eventually have some special sort
> of trigger for maintaining MVs based on base table changes to
> handle the ones that are just too expensive (in developer time or
> run time) to fully automate. But there is a lot of low-hanging
> fru
Robert Haas writes:
> On Tue, Mar 5, 2013 at 7:15 AM, Kevin Grittner wrote:
>> I don't think I disagree with any of what Simon says other than his
>> feelings about the planning cost.
> I'm not sure I agree. Suppose you have a query like SELECT * FROM a
> INNER JOIN b ON a.x = b.x INNER JOIN c
2013/3/5 Robert Haas :
> All that having been said, it's hard for me to imagine that anyone
> really cares about any of this until we have an incremental update
> feature, which right now we don't. Actually, I'm betting that's going
> to be significantly harder than automatic-query-rewrite, when
Robert Haas wrote:
> All that having been said, it's hard for me to imagine that
> anyone really cares about any of this until we have an
> incremental update feature, which right now we don't.
These are actually independent of one another, as long as we nail
down how we're determining "freshnes
Josh Berkus wrote:
There is no shortage of literature on the topic, although any
papers from the ACM could certainly be of interest due to the
general high quality of papers published there. Adding anything
like this to 9.3 is clearly out of the question, though, so I
really don't want to spend
On Tue, Mar 5, 2013 at 7:15 AM, Kevin Grittner wrote:
> I don't think I disagree with any of what Simon says other than his
> feelings about the planning cost. Imagine that there are ten MVs
> that might apply to a complex query, but some of them are mutually
> exclusive, so there are a large num
Simon, Kevin, all:
Actually, there was already an attempt at automated MV query planning as
a prior university project. We could mine that for ideas.
Hmmm. I thought it was on pgfoundry, but it's not. Does anyone have
access to ACM databases etc. so they could search for this?
--
Josh Berku
On 5 March 2013 12:15, Kevin Grittner wrote:
> I don't think I disagree with any of what Simon says other than his
> feelings about the planning cost. Imagine that there are ten MVs
> that might apply to a complex query, but some of them are mutually
> exclusive, so there are a large number of p
Simon Riggs wrote:
> On 3 March 2013 23:39, Tom Lane wrote:
>> Nicolas Barbier writes:
>>> 2013/3/3 Kevin Grittner :
Nicolas Barbier wrote:
> I think that automatically using materialized views even when
> the query doesn’t mention them directly, is akin to
> automatically usin
On 3 March 2013 23:39, Tom Lane wrote:
> Nicolas Barbier writes:
>> 2013/3/3 Kevin Grittner :
>>> Nicolas Barbier wrote:
I think that automatically using materialized views even when the
query doesn’t mention them directly, is akin to automatically
using indexes without having to
On 03-03-2013 21:27, Josh Berkus wrote:
> I think it would be worth talking about when someone wants to implement
> it. I'd imagine it would require setting a GUC, though, which would be
> off by default for obvious reasosn.
>
-1. Why not adding another storage_parameter, say auto_refresh=on? Als
On 03/04/2013 08:27 AM, Josh Berkus wrote:
>> There's a much more fundamental reason why this will never happen, which
>> is that the query planner is not licensed to decide that you only want
>> an approximate and not an exact answer to your query.
> I think it would be worth talking about when so
Kevin Grittner wrote:
> I'm still working on docs, and the changes related to the syntax
> change are still only lightly tested, but as far as I know, all is
> complete except for the docs. I'm still working on those and
> expect to have them completed late today. I'm posting this patch
> to al
> There's a much more fundamental reason why this will never happen, which
> is that the query planner is not licensed to decide that you only want
> an approximate and not an exact answer to your query.
I think it would be worth talking about when someone wants to implement
it. I'd imagine it w
Nicolas Barbier writes:
> 2013/3/3 Kevin Grittner :
>> Nicolas Barbier wrote:
>>> I think that automatically using materialized views even when the
>>> query doesnât mention them directly, is akin to automatically
>>> using indexes without having to mention them in the query.
>> Oh, I understa
2013/3/3 Kevin Grittner :
> Nicolas Barbier wrote:
>
>> I think that automatically using materialized views even when the
>> query doesn’t mention them directly, is akin to automatically
>> using indexes without having to mention them in the query. That
>> way, queries can be written the natural
On Sat, Mar 2, 2013 at 3:06 PM, Kevin Grittner wrote:
>
> (1) Any DML against the MV would need to be limited to some
> context fired by the underlying changes. If we allow changes to
> the MV outside of that without it being part of some "updateable
> MV" feature (reversing the direction of flo
Nicolas Barbier wrote:
> 2013/3/3 Kevin Grittner :
>> Rewriting queries using expressions which match the MV's query
>> to pull from the MV instead of the underlying tables is the
>> exception. While that is a "sexy" feature, and I'm sure one can
>> construct examples where it helps performance,
2013/3/3 Kevin Grittner :
> Rewriting queries using
> expressions which match the MV's query to pull from the MV instead
> of the underlying tables is the exception. While that is a "sexy"
> feature, and I'm sure one can construct examples where it helps
> performance, it seems to me unlikely to
On 03.03.2013 20:06, Kevin Grittner wrote:
The question remains the same, though ... document this usage?
Seems like a good thing to put in an example somewhere.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.po
Kevin Grittner wrote:
> test=# explain analyze select word from words order by word <-> 'caterpiler'
> limit 10;
> Foreign Scan on words
> Total runtime: 218.966 ms
> test=# explain analyze select word from wrd order by word <-> 'caterpiler'
> limit 10;
> Index Scan using wrd_trgm on wrd
> T
In final testing and documentation today, it occurred to me to test
a materialized view with foreign data wrapper. I picked the
file_fdw for convenience, but I think this should work as well with
any other FDW. The idea is to create an MV which mirrors an FDW so
that it can be indexed and quickly
On 3 March 2013 13:12, Kevin Grittner wrote:
> Dean Rasheed wrote:
>> Kevin Grittner wrote:
>
>>> [ ... ] led to this thought:
>>>
>>> REFRESH MATERIALIZED VIEW name [, ...] WITH [ NO ] DATA
>>
>> [Sorry to join this discussion so late]
>>
>> FWIW I had a quick look at other DBs to see if there
Dean Rasheed wrote:
> Kevin Grittner wrote:
>> [ ... ] led to this thought:
>>
>> REFRESH MATERIALIZED VIEW name [, ...] WITH [ NO ] DATA
>
> [Sorry to join this discussion so late]
>
> FWIW I had a quick look at other DBs to see if there were any
> other precedents out there. Oracle was the onl
On 2 March 2013 15:06, Kevin Grittner wrote:
> [ ... ] led to
> this thought:
>
> REFRESH MATERIALIZED VIEW name [, ...] WITH [ NO ] DATA
>
[Sorry to join this discussion so late]
FWIW I had a quick look at other DBs to see if there were any other
precedents out there. Oracle was the only one I
Greg Stark wrote:
> Ants Aasma wrote:
>> To give another example of potential future update semantics, if
>> we were to allow users manually maintaining materialized view
>> contents using DML commands, one would expect TRUNCATE to mean
>> "make this matview empty", not "make this matview unavai
On Fri, Mar 1, 2013 at 3:01 PM, Ants Aasma wrote:
> . To give another example of potential future
> update semantics, if we were to allow users manually maintaining
> materialized view contents using DML commands, one would expect
> TRUNCATE to mean "make this matview empty", not "make this matvie
On Fri, Mar 1, 2013 at 4:18 PM, Kevin Grittner wrote:
> Personally, I don't understand why anyone would want updateable
> materialized views. That's probably because 99% of the cases where
> I've seen that someone wanted them, they wanted them updated to
> match the underlying data using some tec
Ants Aasma wrote:
> Kevin Grittner wrote:
>> Barring a sudden confluence of opinion, I will go with TRUNCATE
>> for the initial spelling. I tend to favor that spelling for
>> several reasons. One was the size of the patch needed to add
>> the opposite of REFRESH to the backend code:
>
> FWIW, I
On Thu, Feb 28, 2013 at 7:52 PM, Kevin Grittner wrote:
> Barring a sudden confluence of opinion, I will go with TRUNCATE for
> the initial spelling. I tend to favor that spelling for several
> reasons. One was the size of the patch needed to add the opposite
> of REFRESH to the backend code:
FW
Heikki Linnakangas wrote:
> On 28.02.2013 16:55, Robert Haas wrote:
>> Well, personally, I'm in favor of either TRUNCATE or ALTER
>> MATERIALIZED VIEW ... DISCARD. I think it's a dangerous
>> precedent to suppose that we're going to start using DISCARD for
>> things that have nothing to do with
On Thu, Feb 28, 2013 at 11:00 AM, Tom Lane wrote:
>> Well, personally, I'm in favor of either TRUNCATE or ALTER
>> MATERIALIZED VIEW ... DISCARD. I think it's a dangerous precedent to
>> suppose that we're going to start using DISCARD for things that have
>> nothing to do with the existing meanin
On 28.02.2013 16:55, Robert Haas wrote:
On Sat, Feb 23, 2013 at 8:00 AM, Michael Paquier
wrote:
it is. http://www.postgresql.org/docs/9.2/static/sql-reset.html
DISCARD would be better.
Well, personally, I'm in favor of either TRUNCATE or ALTER
MATERIALIZED VIEW ... DISCARD. I think it's a d
Robert Haas writes:
> On Sat, Feb 23, 2013 at 8:00 AM, Michael Paquier
> wrote:
>> it is. http://www.postgresql.org/docs/9.2/static/sql-reset.html
>> DISCARD would be better.
> Well, personally, I'm in favor of either TRUNCATE or ALTER
> MATERIALIZED VIEW ... DISCARD. I think it's a dangerous p
On Sat, Feb 23, 2013 at 8:00 AM, Michael Paquier
wrote:
> it is. http://www.postgresql.org/docs/9.2/static/sql-reset.html
> DISCARD would be better.
Well, personally, I'm in favor of either TRUNCATE or ALTER
MATERIALIZED VIEW ... DISCARD. I think it's a dangerous precedent to
suppose that we're
2013-02-19 Kevin Grittner wrote:
[matview-system_views-v2.diff]
I assumed the patches matview-v4.patch and matview-system_views-v2.diff
were to be applied together.
They do apply correctly but during tests, the "test rules ... FAILED".
Perhaps it is solved already but I thought I'd mention
On Sat, Feb 23, 2013 at 9:55 PM, Greg Stark wrote:
> On Sat, Feb 23, 2013 at 1:00 AM, Josh Berkus wrote:
> > I prefer RESET, especially since it could eventually support RESET ALL
> > MATERIALIZED VIEWS if that turns out to be useful. How does the parser
> > like that?
>
> Isn't reset currently
On Sat, Feb 23, 2013 at 1:00 AM, Josh Berkus wrote:
> I prefer RESET, especially since it could eventually support RESET ALL
> MATERIALIZED VIEWS if that turns out to be useful. How does the parser
> like that?
Isn't reset currently only used for GUCs? I think that makes for a
strange crossover.
> That feels completely wrong to me. For one thing, I can't think of
> any ALTER commands to populate or remove data. What did you think
> of the idea of something like DISCARD MATERIALIZED VIEW DATA as a
> new statment? Or maybe RESET MATERIALIZED VIEW?
I prefer RESET, especially since it cou
Andres Freund writes:
> On 2013-02-21 14:11:10 -0800, Kevin Grittner wrote:
>> DISABLE MATERIALIZED VIEW mv; -- ALTER clause for constraints
>> DISCARD MATERIALIZED VIEW DATA mv; -- session state
>> RELEASE MATERIALIZED VIEW DATA mv; -- savepoint
>> RESET MATERIALIZED VIEW DATA mv; -- run-time
On 2013-02-21 14:11:10 -0800, Kevin Grittner wrote:
> Tom Lane wrote:
> > Kevin Grittner writes:
>
> >> What did you think of the idea of something like DISCARD
> >> MATERIALIZED VIEW DATA as a new statment? Or maybe RESET
> >> MATERIALIZED VIEW?
> >
> > I could live with either DISCARD or RESE
Greg Stark wrote:
> Kevin Grittner wrote:
>> It doesn't. That was one of the more contentious points in the
>> earlier bikeshedding phases. Some felt that throwing away the
>> contents was a form of making the MV "out of date" and as such
>> didn't require any special handling. Others, includi
On Thu, Feb 21, 2013 at 2:38 PM, Kevin Grittner wrote:
> It doesn't. That was one of the more contentious points in the
> earlier bikeshedding phases. Some felt that throwing away the
> contents was a form of making the MV "out of date" and as such
> didn't require any special handling. Others,
Tom Lane wrote:
> Kevin Grittner writes:
>> What did you think of the idea of something like DISCARD
>> MATERIALIZED VIEW DATA as a new statment? Or maybe RESET
>> MATERIALIZED VIEW?
>
> I could live with either DISCARD or RESET.
I figured this was worth a pass through the keyword list to look
On 2/21/13 9:25 AM, Kevin Grittner wrote:
> Peter Eisentraut wrote:
>> On 2/20/13 11:14 PM, Greg Stark wrote:
>>> That's not entirely true. From the database's point of view,
>>> TRUNCATE is in many ways actually DDL.
>>
>> Whether something is DDL or DML or a read operation (query) is
>> not an i
1 - 100 of 273 matches
Mail list logo
