#44: Ensure frmEditGrid survives a drop/create of the underlying relation
---+
Reporter: Mark Murawski | Owner: ashesh.vashi
Type: bug| Status: new
Priority: minor
#44: Ensure frmEditGrid survives a drop/create of the underlying relation
---+
Reporter: Mark Murawski | Owner: ashesh.vashi
Type: bug| Status: new
Priority: minor
Hi,
It seems strange to me that nobody else reported this behavior, maybe a
bug.
It just me or what ?. :-).
Today I compiled revision 4455, with an updated postgresql 8.1 beta 2
and still can't modify any table due to "ADD before DROP" issue.
It seems to happen only in table properties dialog.
Hi:
I just realized that I am having the following trouble :
If open properties of a table, to adding a column i.e., and that table
has some constraints, the SQL tab show code similar to :
ALTER TABLE circulation.deliveries ADD CONSTRAINT
deliveries_delivery_type_id_fk FOREIGN KEY (delivery_type
> -Original Message-
> From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]]
> Sent: 30 October 2001 11:08
> To: Dave Page
> Cc: [EMAIL PROTECTED]
> Subject: RE: DROP/CREATE
>
>
>
> >Yes, I agree. As I said in my first message, there is no
> problem
>Yes, I agree. As I said in my first message, there is no problem with
>standalone views, but (and this is the killer) if your view is a dependency
>of something else like an SQL function or another view then you have a
>problem. The problem is even bigger (i.e. harder to detect) if the rowtype
>
> -Original Message-
> From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]]
> Sent: 30 October 2001 10:39
> To: [EMAIL PROTECTED]
> Cc: dave Page; [EMAIL PROTECTED]
> Subject: RE: DROP/CREATE
>
>
>
> >Yes (and I agree that it would be a good
>Yes (and I agree that it would be a good feature), but that will still
>require full client side parsing of the code to figure out the dependencies
>- I for one, do not wish to try to recreate (and keep up-to-date) the
>PostgreSQL parser in VB. Besides which, if we take it that far then we might
> -Original Message-
> From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]]
> Sent: 30 October 2001 09:21
> To: Dave Page
> Cc: [EMAIL PROTECTED]
> Subject: RE: DROP/CREATE
>
> What if that
> >function takes an entire tuple from a
> >(modified)
>I don't think rules are an issue are they? Can you create them on Views
>(certainly pgAdmin won't let you - should it?) - scrub that, (typing as I
>think!) how else would you create an updateable view using rules? Does the
>same apply to triggers i.e. can you create them on views?
Yes you can. T
> -Original Message-
> From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]]
> Sent: 30 October 2001 07:57
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: DROP/CREATE
>
>
> > For a 'standalone' view, this is fin
> For a 'standalone' view, this is fine, but if the view is used in
another view or a function then that will break (I think I'm teaching my
Grandmother to suck eggs here Jean-Michel!).
> 1) Attempt to create a view with the new definition to ensure it's valid.
> 2) Drop the old view.
> 3) C
[resent...]
> -Original Message-
> From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]]
> Sent: 21 October 2001 15:27
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: DROP/CREATE
>
>
> Hello Dave and all,
>
> Views are based on OIDs and the
> -Original Message-
> From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]]
> Sent: 21 October 2001 15:27
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: DROP/CREATE
>
>
> Hello Dave and all,
>
> Views are based on OIDs and there is no
Hello Dave and all,
Views are based on OIDs and there is not simple way to implement
DROP/CREATE VIEW in pgAdmin II. Seems more easy for CREATE OR REPLACE
TRIGGER. I posted today a mail on pg-hackers to ask if someone could
implement CREATE OR REPLACE directly in PostgreSQL.
Cheers,
Jean
15 matches
Mail list logo
