On Tue, 23 Oct 2001 17:16:06 +0200, you wrote:
CREATE OR DROP VIEW
Is this for real? If I were a database server I would say to the
client please make up your mind :-)
Regards,
René Pijlman [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1:
CREATE OR DROP VIEW
Is this for real? If I were a database server I would say to the
client please make up your mind :-)
I meant DROP IF EXISTS and then CREATE.
This is more simple to implement than CREATE OR REPLACE.
Best regards,
Jean-Michel POURE
---(end of
I have added this to the TODO list:
* Add OR REPLACE clauses to non-FUNCTION object creation
I think there are clearly some other objects that need OR REPLACE. Not
sure which ones yet.
---
Dear all,
Would
Bruce Momjian [EMAIL PROTECTED] writes:
Our current CREATE OR REPLACE FUNCTION perserves the OID of the
function. Is there similar functionality you need where a simple
DROP (ignore the error), CREATE will not work?
If possible, it's nice to not have commands whose error codes you ignore.
On Tue, 23 Oct 2001, Bruce Momjian wrote:
Dear all,
Would it be possible to implement CREATE OR REPLACE VIEW / TRIGGER in
PostgreSQL 7.2?
Probably not, it's rather late in the cycle (isn't beta imminent?). Oh,
I'd vote for OR REPLACE as there's already an opt_or_replace
non-terminal in
Not until we do the necessary legwork. I spent a good deal of time over
the past week making the various PL modules react to replacement of
pg_proc entries by CREATE OR REPLACE FUNCTION (cf. complaint from Peter
a week or so back). CREATE OR REPLACE VIEW implies updating cached
query
Bruce Momjian wrote:
Alternatively, could someone implement CREATE OR DROP VIEW / TRIGGER? These
features are needed for pgAdmin II (we could also provide a patch for
PhpPgAdmin). If this cannot be implemented in PostgreSQL, we will go for
pseudo-modification solutions (which is
On Tue, 23 Oct 2001, Bruce Momjian wrote:
If possible, it's nice to not have commands whose error codes you ignore.
That way if you see an error, you know you need to do something about it.
Folks, is this a valid reason for adding OR REPLACE to all CREATE object
commands?
Sounds good to
Bill Studenmund writes:
Our current CREATE OR REPLACE FUNCTION perserves the OID of the
function. Is there similar functionality you need where a simple
DROP (ignore the error), CREATE will not work?
If possible, it's nice to not have commands whose error codes you ignore.
That way if
Jean-Michel POURE [EMAIL PROTECTED] writes:
Would it be possible to implement CREATE OR REPLACE VIEW / TRIGGER in
PostgreSQL 7.2?
We're already vastly overdue for beta. The time for new feature
requests for 7.2 is past ... especially nontrivial requests.
regards, tom
Dear all,
Would it be possible to implement CREATE OR REPLACE VIEW / TRIGGER in
PostgreSQL 7.2?
Alternatively, could someone implement CREATE OR DROP VIEW / TRIGGER? These
features are needed for pgAdmin II (we could also provide a patch for
PhpPgAdmin). If this cannot be implemented in
Dear all,
Would it be possible to implement CREATE OR REPLACE VIEW / TRIGGER in
PostgreSQL 7.2?
Alternatively, could someone implement CREATE OR DROP VIEW / TRIGGER? These
features are needed for pgAdmin II (we could also provide a patch for
PhpPgAdmin). If this cannot be implemented
Alternatively, could someone implement CREATE OR DROP VIEW / TRIGGER? These
features are needed for pgAdmin II (we could also provide a patch for
PhpPgAdmin). If this cannot be implemented in PostgreSQL, we will go for
pseudo-modification solutions (which is definitely not a good
We are also waiting for a proper ALTER table DROP column but we are day
dreamers...
This is a good example of bad management on our parts. We couldn't
decide between two possible DROP COLUMN implementations, so we now have
the worst result, which is no implementation at all.
--
Bruce
14 matches
Mail list logo
