-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 variants
>>> 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
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
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
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 ru
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:
S
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 th
-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 vi
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
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, tha
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 shoul
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 c
12 matches
Mail list logo
