Robert Haas robertmh...@gmail.com writes:
On Wed, May 28, 2014 at 8:22 AM, ash a...@commandprompt.com 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 PostgreSQL to just re
Tom Lane t...@sss.pgh.pa.us writes:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jun 2, 2014 at 8:52 AM, ash a...@commandprompt.com 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
Robert Haas robertmh...@gmail.com 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
Stephen Frost sfr...@snowman.net 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
Stephen Frost sfr...@snowman.net writes:
* ash (a...@commandprompt.com) wrote:
Stephen Frost sfr...@snowman.net 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 do that
anyway, though
Tom Lane t...@sss.pgh.pa.us 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
David Fetter da...@fetter.org 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
deterministic
Robert Haas robertmh...@gmail.com 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:
David G Johnston david.g.johns...@gmail.com 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)
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
David Fetter da...@fetter.org 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/cab7npqtlmmn1ltb5we0v0do57ip0u73ykwzbzytaxdf1caw
11 matches
Mail list logo
