2010/10/20 Merlin Moncure :
> In recent versions of postgres (I think 8.4+?) you can add columns to
> the view via create/replace (not drop of course). This greatly
> reduces the practical annoyances of dropping view dependencies, at
> least for me...
Ok, We're still on 8.3 here, and management re
2010/10/19 Grzegorz Jaśkiewicz :
> On Tue, Oct 19, 2010 at 3:12 PM, Tom Lane wrote:
>> Ravi Katkar writes:
>>> Is there any feature to drop the view with out cascading the dependents.
>>
>> No. But why don't you use CREATE OR REPLACE VIEW?
>>
> only caveat is, it won't work if he adds/removes an
You can always recreate the dependent views in the same process, since you
won't lose any data. If there are also linked tables you could use COPY
before deleting and recreating, it's fairly fast.
But..does the structure of your data really need to change? Just guessing,
but it just sounds a littl
pgsql-general@postgresql.org
Subject: Re: [GENERAL] drop view with out cascading the dependents
On Tue, Oct 19, 2010 at 3:12 PM, Tom Lane wrote:
> Ravi Katkar writes:
>> Is there any feature to drop the view with out cascading the dependents.
>
> No. But why don't you use CREAT
On Tue, Oct 19, 2010 at 3:12 PM, Tom Lane wrote:
> Ravi Katkar writes:
>> Is there any feature to drop the view with out cascading the dependents.
>
> No. But why don't you use CREATE OR REPLACE VIEW?
>
only caveat is, it won't work if he adds/removes any columns. CREATE
OR REPLACE VIEW is rathe
Ravi Katkar writes:
> Is there any feature to drop the view with out cascading the dependents.
No. But why don't you use CREATE OR REPLACE VIEW?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription
Vick Khera wrote:
> On Fri, Oct 23, 2009 at 6:44 PM, Sydney Puente wrote:
>> Ah I see what you mean - thanks very much that is v helpful!
>> Yes the copy will be read-only.
>> Will have 3 tables of data, being read (readonly) and in the background
>> Will have 3 shadow tables populated from an unr
On Fri, Oct 23, 2009 at 6:44 PM, Sydney Puente wrote:
> Ah I see what you mean - thanks very much that is v helpful!
> Yes the copy will be read-only.
> Will have 3 tables of data, being read (readonly) and in the background
> Will have 3 shadow tables populated from an unreliable db over an unrel
On Fri, Oct 23, 2009 at 2:45 AM, Sydney Puente wrote:
> This data will be accessed a couple of times a second, and I have a cunning
> plan to have a view that points to the initial dataload, and then load up
> the new data into a shadow table, drop the view and then recreate it
> pointing to the
[EMAIL PROTECTED] ("Christian Rengstl") writes:
> Whenever I try dropping a view using DROP VIEW myschema.myview the
> query runs forever. The last time I tried was ten minutes ago and the
> query is still running even though the view queries just data of one
> single table with around 5 fields.
>
am Wed, dem 17.10.2007, um 13:01:25 +0200 mailte Christian Rengstl folgendes:
> Hi list,
>
> Whenever I try dropping a view using DROP VIEW myschema.myview the
> query runs forever. The last time I tried was ten minutes ago and the
> query is still running even though the view queries just data o
Nevermind, by mistake I tried dropping it as a different user. But, just
a question, wouldn't it make more sense to issue an error message or
something instead of letting the query run indefinitely?
Christian Rengstl M.A.
Klinik und Poliklinik für Innere Medizin II
Kardiologie - Forschung
Univer
Keith Siu <[EMAIL PROTECTED]> writes:
> I ve made a mistake to create a view " all staff" and can't drop it
> everytime I descript or drop the view , it appear Error as below :
> template1> \d all staff;
> ERROR: nodeRead : Bad type 0
> template1>drop view all staff;
> ERROR :parser: parser erro
13 matches
Mail list logo
