Le 7 mai 08 à 07:52, Tom Lane a écrit :
Dimitri Fontaine [EMAIL PROTECTED] writes:
Could we consider ALTER VIEW ALTER COLUMN ... SET DEFAULT ...;?
We could if we hadn't already done it five or so years ago.
Or am I missing what you need here?
My 8.3.1 installation psql \h only gives me:
Le mercredi 07 mai 2008, Dimitri Fontaine a écrit :
Ok, I've been quite bad at explaining the case, let's retry.
Thanks a lot to the OP on #postgresqlfr (nickname renchap), who is providing
attached test case, where you'll see how we hacked our way into
information_schema to have the insert
Dimitri Fontaine wrote:
Le 7 mai 08 à 07:52, Tom Lane a écrit :
Dimitri Fontaine [EMAIL PROTECTED] writes:
Could we consider ALTER VIEW ALTER COLUMN ... SET DEFAULT ...;?
We could if we hadn't already done it five or so years ago.
Or am I missing what you need here?
My 8.3.1 installation
Dimitri Fontaine [EMAIL PROTECTED] writes:
My 8.3.1 installation psql \h only gives me:
Syntax:
ALTER VIEW name RENAME TO newname
You're not the first person to think that ALTER VIEW covers everything
that can be done to a view.
I'm starting to think that we should just make ALTER VIEW be an
Tom Lane [EMAIL PROTECTED] wrote:
Dimitri Fontaine [EMAIL PROTECTED] writes:
My 8.3.1 installation psql \h only gives me:
Syntax:
ALTER VIEW name RENAME TO newname
You're not the first person to think that ALTER VIEW covers
everything
that can be done to a view.
I'm starting to think
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 7 mai 08 à 16:26, Tom Lane a écrit :
I'm starting to think that we should just make ALTER VIEW be an alias
for ALTER TABLE (rather than a separate node type as now), and then
list
in the ALTER VIEW reference page all of the ALTER TABLE
I have a client who is looking for a way to be able to alter objects
without having to recreate (say, from a dump) all the objects in a
possibly large dependency tree rooted at the object. Of course, if the
alteration invalidates the dependency, than this operation should fail,
but adding a
Andrew Dunstan wrote:
I have a client who is looking for a way to be able to alter objects
without having to recreate (say, from a dump) all the objects in a
possibly large dependency tree rooted at the object. Of course, if the
alteration invalidates the dependency, than this operation
Josh Berkus wrote:
Andrew Dunstan wrote:
I have a client who is looking for a way to be able to alter objects
without having to recreate (say, from a dump) all the objects in a
possibly large dependency tree rooted at the object. Of course, if
the alteration invalidates the dependency,
Andrew Dunstan [EMAIL PROTECTED] writes:
Josh Berkus wrote:
I don't follow you. I can currently add a column, without breaking
either foriegn keys or inheritance. What's the problem?
not for a view at least.
Yeah, the restrictions on replacing a view definition date from before
we had any
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 6 mai 08 à 19:44, Tom Lane a écrit :
Andrew Dunstan [EMAIL PROTECTED] writes:
Josh Berkus wrote:
I don't follow you. I can currently add a column, without breaking
either foriegn keys or inheritance. What's the problem?
not for a
Dimitri Fontaine [EMAIL PROTECTED] writes:
Could we consider ALTER VIEW ALTER COLUMN ... SET DEFAULT ...;?
We could if we hadn't already done it five or so years ago.
Or am I missing what you need here?
Bonus question: why is the rewriter unable to distinguish whether NULL
comes from the
12 matches
Mail list logo
