On Mon, Jun 02, 2014 at 01:29:25PM -0400, Robert Haas wrote:
I agree, but I think it's important to note that Alex's complaint is
not unique - the way things work now is a real source of frustration
for users. In a previous job, I wrote a schema-upgrade script that
dropped all of the views in
On Mon, Jun 2, 2014 at 10:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I can see two answers. Answer #1 is
that the column type of bar.a changes from int to bigint and the view
definition is still SELECT a FROM foo. In that case, showing the user
the SQL does not help them see and approve
On Tuesday, June 3, 2014, Robert Haas [via PostgreSQL]
ml-node+s1045698n5805857...@n5.nabble.com wrote:
On Mon, Jun 2, 2014 at 10:00 PM, Tom Lane [hidden email]
http://user/SendEmail.jtp?type=nodenode=5805857i=0 wrote:
I can see two answers. Answer #1 is
that the column type of bar.a
Robert Haas robertmh...@gmail.com writes:
On Mon, Jun 2, 2014 at 10:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Or something else; I don't claim to be a good UI designer. But in the
end, this is 90% a UI problem, and that means that raw SQL is seriously
poorly suited to solve it directly.
I
On Tue, Jun 3, 2014 at 10:14 AM, Tom Lane t...@sss.pgh.pa.us wrote:
If we had such a mechanism,
then perhaps someone could build a UI providing the sort of user
feedback you're suggesting to help them use it more safely. But isn't
the core server support the first thing?
I'm guessing you
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 3, 2014 at 10:14 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm guessing you did not read
http://www.postgresql.org/message-id/18723.1401734...@sss.pgh.pa.us
Argh, sorry, I saw that go by and it went past my eyes but obviously I
didn't really
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-parse the *current* view
definition. Should
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
Robert Haas robertmh...@gmail.com writes:
What exactly do you mean by re-parse the current view definition?
The only form of the view definition we actually have is already
parsed into an internal form (see pg_rewrite) which, for the reasons
I've attempted to explain, is not easy to adapt to
On Mon, Jun 2, 2014 at 8:52 AM, ash a...@commandprompt.com wrote:
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
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 the point that I'm making,
which is that we
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 the
On Mon, Jun 2, 2014 at 10:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
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
Robert Haas robertmh...@gmail.com writes:
On Mon, Jun 2, 2014 at 10:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The real problem in my mind is one of user expectations. If the database
silently does something behind your back, people expect that that action
will be *right* and they don't have
* Robert Haas (robertmh...@gmail.com) wrote:
On Mon, Jun 2, 2014 at 10:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The real problem in my mind is one of user expectations. If the database
silently does something behind your back, people expect that that action
will be *right* and they don't
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Robert Haas robertmh...@gmail.com writes:
I agree, but I think it's important to note that Alex's complaint is
not unique - the way things work now is a real source of frustration
for users.
Oh, I quite agree with that. My concern here has to do
On 06/02/2014 10:40 AM, Stephen Frost wrote:
Tom's point goes back to what I was trying to drive at originally-
people should have to ask for this. Perhaps we can provide a way for
them to ask which is explicit enough that they understand this might
not do exactly what you think it does, akin
On 2014-06-02 10:48:02 -0700, Josh Berkus wrote:
On 06/02/2014 10:40 AM, Stephen Frost wrote:
Tom's point goes back to what I was trying to drive at originally-
people should have to ask for this. Perhaps we can provide a way for
them to ask which is explicit enough that they understand
On 2014-06-02 13:40:32 -0400, Stephen Frost wrote:
Of course, there is a question about if it's worth it to keep around the
exact text of each CREATE VIEW and build all this infrastructure for
something which will only work properly in a specific subset of cases
and in many others could break
Tom Lane wrote:
Oh, I quite agree with that. My concern here has to do with automatically
and silently making changes that we can't be very sure will meet the
user's expectations. Perhaps what we need is some kind of UI/API design
whereby the user can inspect/modify/approve the semantic
On Mon, Jun 2, 2014 at 1:40 PM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Mon, Jun 2, 2014 at 10:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The real problem in my mind is one of user expectations. If the database
silently does something behind
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane wrote:
Oh, I quite agree with that. My concern here has to do with automatically
and silently making changes that we can't be very sure will meet the
user's expectations. Perhaps what we need is some kind of UI/API design
whereby the
Robert Haas robertmh...@gmail.com writes:
FWIW, I don't think reparsing the original view-text is even remotely
plausible. The fact that views stay glued to the same objects even of
those objects are renamed is a pretty handy property of the current
system, and any sort of
On Mon, Jun 2, 2014 at 2:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Deparse-and-reparse might be better, but I'll bet that has too
many problems to be viable, too (even if I haven't yet thought of what
they are). For better or for worse, I think the best we're likely to
be able to do is
Robert Haas robertmh...@gmail.com writes:
On Mon, Jun 2, 2014 at 2:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think deparse-and-reparse is exactly what we have to do, mainly because,
if you subscribe to the idea that the user should see and approve semantic
changes, what else are we going to
* Robert Haas (robertmh...@gmail.com) wrote:
On Mon, May 26, 2014 at 10:39 AM, Stephen Frost sfr...@snowman.net wrote:
It'd need to be explicitly requested, eg a 'CASCADE' option.
Why? Would any sane person NOT want this behavior?
[...]
Now maybe there are options other than trying to
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
* ash (a...@commandprompt.com) wrote:
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
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
* ash (a...@commandprompt.com) wrote:
What I am suggesting is that we try to detect such breakage at the time
the user runs ALTER TABLE (issuing NOTICE or ERROR at user discretion.)
If changing column type of a table breaks some functions down the way,
the user will hit it anyway, but better
ash a...@commandprompt.com writes:
Stephen Frost sfr...@snowman.net writes:
We're not going to re-parse every function in the system, like, ever.
Well, only every *affected* function, which might be pretty minimal in
the usual case.
We don't store dependency information for function bodies,
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
ash wrote:
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.
OK, forget functions, I now realize it's not feasible to consider.
Can we get back to re-defining views at
* ash (a...@commandprompt.com) wrote:
OK, forget functions, I now realize it's not feasible to consider.
I never meant to imply that it was but rather to point out that we might
have users who actually want to get an error when they're changing a
type definition which goes beyond the scope of
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
On Mon, May 26, 2014 at 10:39 AM, Stephen Frost sfr...@snowman.net wrote:
* ash (a...@commandprompt.com) wrote:
This came up recently on general list (and I've just hit the same issue
today):
Alexander Shulgin 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/
CAB7nPqTLmMn1LTb5WE0v0dO57iP0U73yKwzbZytAXDF1CAWLZg@.gmail
Why couldn't postgres re-create the dependent views automatically? I
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)
On Tue, May 27, 2014 at 11:20 PM, ash a...@commandprompt.com wrote:
Now, consider the situation in which we want to achieve the same
result without having to drop and recreate v. When the column type of
t.a is changed, we can use the dependencies to figure out that v might
be impacted. We
ash,
* ash (a...@commandprompt.com) wrote:
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
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...@mail.gmail.com
Why couldn't postgres re-create the
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):
On Tue, May 27, 2014 at 12:37:32AM +0400, ash wrote:
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):
45 matches
Mail list logo
