Tom Lane writes:
> Robert Haas writes:
>> On Mon, Jun 2, 2014 at 8:52 AM, ash wrote:
>>> Should this fail, the user will have to work around it, but most of the
>>> time it could just work.
>
>> You're either missing or choosing to ignore the point th
Robert Haas writes:
> On Wed, May 28, 2014 at 8:22 AM, ash wrote:
>>> None of that involves answering hypothetical questions; but what you
>>> want to do does, and that I think is the problem in a nutshell.
>>
>> In a nutshell I'd like PostgreS
Tom Lane writes:
>
> We don't store dependency information for function bodies, so there's
> no way to do this except by reparsing everything in sight.
>
> A larger issue with the idea is that a function might fail reparsing
> for reasons having nothing to do with the proposed ALTER TABLE.
> For
Stephen Frost writes:
> * ash (a...@commandprompt.com) wrote:
>> Stephen Frost writes:
>>
>> > Also consider MatViews which would need to be rewritten for the new
>> > type
>>
>> That might be costly but not impossible. A user would need to
Stephen Frost writes:
>
> I hadn't even considered the idea that we would go through and try to
> change everything which referenced that view to now be the new type- but
> in that case, I'd want to know that there were other changes which were
> happening beyond the single view which I was updat
Robert Haas writes:
>
> Well, pg_dump is trying to do something different than what you're
> trying to do here. pg_dump wants to make sure that the view, when fed
> back into psql, creates the same view that exists now, regardless of
> whether that's what the user created originally. For exampl
David G Johnston writes:
>
> Would it be possible to handle the specific case of varchar(n) to
> varchar/text by just ignoring the error?
Simply for the reference, my case is INT to BIGINT.
--
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Robert Haas writes:
>>
>> It'd need to be explicitly requested, eg a 'CASCADE' option.
>
> Why? Would any sane person NOT want this behavior?
>
> I think the question here is whether there's any way to make this work
> at all, not whether we'd want it if we could get it. Consider:
>
> CREATE OR
David Fetter writes:
>> >
>> > Also worth considering: functions which take any part of the view
>> > as a parameter.
>>
>> Sorry, I don't get it: do you suggest we should re-create dependent
>> functions too?
>
> I'd throw an error in cases where such functions had an obvious and
> deterministi
David Fetter writes:
> On Mon, May 26, 2014 at 06:25:09PM +0400, ash wrote:
>> Hi Hackers,
>>
>> This came up recently on general list (and I've just hit the same issue
>> today):
>>
>> http://www.postgresql.org/message-id/cab7npqtlmmn1ltb5we0v0
Hi Hackers,
This came up recently on general list (and I've just hit the same issue today):
http://www.postgresql.org/message-id/cab7npqtlmmn1ltb5we0v0do57ip0u73ykwzbzytaxdf1caw...@mail.gmail.com
Why couldn't postgres re-create the dependent views automatically? I
mean it knows which views d
11 matches
Mail list logo
