Обсуждение: public schema not prefixed / copy + paste adds newline
Hi Both these issues are also present in the 1.6 series :- public schema prefix not added to any scripts =========================== This exists in 1.6 as well, but if you have a login that is also the name of a schema and you edit a public anything using CREATE script then "public." is not added to the object. This means that when you execute the object is stored in your schema not public. So every time you use CREATE script you have to add set search_path to public first which is a bit tiresome and error prone. Copy and paste from edit grid adds a newline =========================== If you double click on a text field in the grid and do ctrl-c then paste the result into another text field you get a newline on the end. My users do this all the time and I am constantly writing triggers to prevent this from happening. Many thanks for great product Kieran
Kieran McCusker wrote: > Hi > > Both these issues are also present in the 1.6 series :- > > public schema prefix not added to any scripts > =========================== > > This exists in 1.6 as well, but if you have a login that is also the > name of a schema and you edit a public anything using CREATE script then > "public." is not added to the object. This means that when you execute > the object is stored in your schema not public. > > So every time you use CREATE script you have to add set search_path to > public first which is a bit tiresome and error prone. This works for me - if you look at the database properties, what does it report as your default database? > Copy and paste from edit grid adds a newline > =========================== > > If you double click on a text field in the grid and do ctrl-c then paste > the result into another text field you get a newline on the end. My > users do this all the time and I am constantly writing triggers to > prevent this from happening. Unfortunately this happens in the cases when the underlying control as supplied by the OS handles the paste. I can reproduce it in Windows XP, but it's a Microsoft control that's adding the \n :-( Regards, Dave
Kieran McCusker wrote:
> Dave
>
> I am logged on as user portal and there is a schema portal, select
> current_schemas(false) reports {portal,public} my default schema is public.
> Does this give you a clue?
What does
show search_path;
return (exactly - spelling, case, quoting etc)?
Regards, Dave.
Kieran McCusker wrote: > Dave > > show search_path returns : "$user",public Ah-ha - I tested on EnterpriseDB which misses the quotes (which I guess were added in PostgreSQL at some point). I've changed the code to allow for possible quotes - will commit shortly. Thanks for the report. Regards, Dave.
On Jul 19, 4:53 pm, dp...@postgresql.org (Dave Page) wrote: > Kieran McCusker wrote: (...) > > Copy and paste from edit grid adds a newline > > =========================== > > > If you double click on a text field in the grid and do ctrl-c then paste > > the result into another text field you get a newline on the end. My > > users do this all the time and I am constantly writing triggers to > > prevent this from happening. > > Unfortunately this happens in the cases when the underlying control as > supplied by the OS handles the paste. I can reproduce it in Windows XP, > but it's a Microsoft control that's adding the \n :-( We have been discussing this a couple of months back. I think there is a misunderstanding involved. The newline is _not_ added at paste time, it is appended to the string in the text field to begin with. You can deselect the character before copying, which results in pasting without newline. You can even select this non-printing character at the end of the string exclusively. I experimented a bit with it. Weird thing is: You cannot paste the character in the SQL dialogue window or scratch pad. You can, however, paste it in a text field in the edit grid - causing problems. You can, on the other hand, not insert the character in a timestamp field in the edit grid. But then again, you cannot paste \n in that field, either. You can, however, paste \r. You can also paste this character it in other applications, like OOo for instance, which results in a newline: \r\n So the problem is the special character that is appended to text in text fields in the edit grid. Does not happen with numbers or timestamps. You can copy / paste those without problems. You can, for instance, copy a timestamp from a timestamp field and paste it in a text field and not suffer the unwanted line break. I am not sure which character it actually is (EOF? Maybe somebody can enlighten us?), but it should not be there. I suspect more problems stemming from inconsitent treatment of \n, \r and \r\n among the various windows: SQL dialogue / edit grid / output pane. I have experimented a lot with tests like this: select e'X\r\nX' select e'X\n\rX' Regards Erwin
Sorry, I was in the process of editing my post, when the groups.google.com decided to interpret "<tab><tab> -" as my will to send it. So the posting above is quite unfinished. �$%&/( interface! : ( Anyway, here is what my finished posting would look like: On Jul 19, 4:53 pm, dp...@postgresql.org (Dave Page) wrote: > Kieran McCusker wrote: (...) > > Copy and paste from edit grid adds a newline > > =========================== > > > If you double click on a text field in the grid and do ctrl-c then paste > > the result into another text field you get a newline on the end. My > > users do this all the time and I am constantly writing triggers to > > prevent this from happening. > > Unfortunately this happens in the cases when the underlying control as > supplied by the OS handles the paste. I can reproduce it in Windows XP, > but it's a Microsoft control that's adding the \n :-( We have been discussing this before. I think there is a misunderstanding involved. The newline is not appended at paste time, it is appended in the text field in the edit grid BEFORE copying. You can de-select the appended non-printing character in the text field in the edit grid before copying, which results in the desired behaviour. You can even exclusively select the culprit character and .. paste it in a text field in the edit grid. Results in a newline. .. cannot paste it in fields of other type in the edit grid (like timestamp). But then again, you cannot enter \n in a timestamp field at all. (You can however enter \r, which results in gibberish character.) .. cannot paste it in the scratch pad or the SQL query dialogue. Results in nothing. .. can paste it in other applications like OOo. Results in a line break (\r\n). If you copy that one back to a text field in the edit grid you get two new lines. I am not sure which character is appended to the text in text fields in the edit grid, but it should not be there. I suspect confusion in the handling of \n, \r and \r\n. Regards Erwin
On Jul 19, 4:53 pm, dp...@postgresql.org (Dave Page) wrote: > Kieran McCusker wrote: (...) > > Copy and paste from edit grid adds a newline > > =========================== > > > If you double click on a text field in the grid and do ctrl-c then paste > > the result into another text field you get a newline on the end. My > > users do this all the time and I am constantly writing triggers to > > prevent this from happening. > > Unfortunately this happens in the cases when the underlying control as > supplied by the OS handles the paste. I can reproduce it in Windows XP, > but it's a Microsoft control that's adding the \n :-( We have been discussing this a couple of months back. I think there is a misunderstanding involved. The newline is _not_ added at paste time, it is appended to the string in the text field to begin with. You can deselect the character before copying, which results in pasting without newline. You can even select this non-printing character at the end of the string exclusively. I experimented a bit with it. Weird thing is: You cannot paste the character in the SQL dialogue window or scratch pad. You can, however, paste it in a text field in the edit grid - causing problems. You can, on the other hand, not insert the character in a timestamp field in the edit grid. But then again, you cannot paste \n in that field, either. You can, however, paste \r. You can also paste this character it in other applications, like OOo for instance, which results in a newline: \r\n So the problem is the special character that is appended to text in text fields in the edit grid. Does not happen with numbers or timestamps. You can copy / paste those without problems. You can, for instance, copy a timestamp from a timestamp field and paste it in a text field and not suffer the unwanted line break. I am not sure which character it actually is (EOF? Maybe somebody can enlighten us?), but it should not be there. I suspect more problems stemming from inconsitent treatment of \n, \r and \r\n among the various windows: SQL dialogue / edit grid / output pane. I have experimented a lot with tests like this: select e'X\r\nX' select e'X\n\rX' Regards Erwin
Sorry, I was in the process of editing my post, when the groups.google.com decided to interpret "<tab><tab> -" as my will to send it. So the posting above is quite unfinished. �$%&/( interface! : ( Anyway, here is what my finished posting would look like: On Jul 19, 4:53 pm, dp...@postgresql.org (Dave Page) wrote: > Kieran McCusker wrote: (...) > > Copy and paste from edit grid adds a newline > > =========================== > > > If you double click on a text field in the grid and do ctrl-c then paste > > the result into another text field you get a newline on the end. My > > users do this all the time and I am constantly writing triggers to > > prevent this from happening. > > Unfortunately this happens in the cases when the underlying control as > supplied by the OS handles the paste. I can reproduce it in Windows XP, > but it's a Microsoft control that's adding the \n :-( We have been discussing this before. I think there is a misunderstanding involved. The newline is not appended at paste time, it is appended in the text field in the edit grid BEFORE copying. You can de-select the appended non-printing character in the text field in the edit grid before copying, which results in the desired behaviour. You can even exclusively select the culprit character and .. paste it in a text field in the edit grid. Results in a newline. .. cannot paste it in fields of other type in the edit grid (like timestamp). But then again, you cannot enter \n in a timestamp field at all. (You can however enter \r, which results in gibberish character.) .. cannot paste it in the scratch pad or the SQL query dialogue. Results in nothing. .. can paste it in other applications like OOo. Results in a line break (\r\n). If you copy that one back to a text field in the edit grid you get two new lines. I am not sure which character is appended to the text in text fields in the edit grid, but it should not be there. I suspect confusion in the handling of \n, \r and \r\n. Regards Erwin
Erwin Brandstetter wrote: > We have been discussing this before. I think there is a > misunderstanding involved. The newline is not appended at paste time, > it is appended in the text field in the edit grid BEFORE copying.> > You can de-select the appended non-printing character in the text > field in the edit grid before copying, which results in the desired > behaviour. Right - I see the problem. There's an extra 'char' on the end of the line which can indeed be de-selected. That is actually RTF formatting code (we use the RTF text boxes on Windows for large strings because otherwise we get restricted to 64K or something silly). The problem is though, that it remains the underlying controls that are doing the copy and the paste operations so we still have no way in pgAdmin to filter it out. You can actually test this by pasting using the button to do it - that does use our code which ensures it pastes plain text (thus losing the RTF cruft that causes the 'newline'. The problem is that the controls don't allow us to override their paste hotkeys - at least if they do, it needs some unusual foo that I've yet to stumble across. Regards, Dave.
Dave Page wrote: > The problem is though, that it remains the underlying controls that > are doing the copy and the paste operations so we still have no way in > pgAdmin to filter it out. You can actually test this by pasting using > the button to do it - that does use our code which ensures it pastes > plain text (thus losing the RTF cruft that causes the 'newline'. The > problem is that the controls don't allow us to override their paste > hotkeys - at least if they do, it needs some unusual foo that I've yet > to stumble across. Just to make sure .. Not copying and pasting is the root of the problem, but the incorrect representation of the text to begin with. This appended character should not be there, at least not selectable. Maybe you have a way to avoid the appendix, thus avoiding also the need to override copy / paste hotkeys? If that is a no-go, too, then where can we file a bug report? Regards Erwin
Erwin Brandstetter wrote: > Dave Page wrote: >> The problem is though, that it remains the underlying controls that >> are doing the copy and the paste operations so we still have no way in >> pgAdmin to filter it out. You can actually test this by pasting using >> the button to do it - that does use our code which ensures it pastes >> plain text (thus losing the RTF cruft that causes the 'newline'. The >> problem is that the controls don't allow us to override their paste >> hotkeys - at least if they do, it needs some unusual foo that I've yet >> to stumble across. > > Just to make sure .. > Not copying and pasting is the root of the problem, but the incorrect > representation of the text to begin with. This appended character should > not be there, at least not selectable. > Maybe you have a way to avoid the appendix, thus avoiding also the need > to override copy / paste hotkeys? > > If that is a no-go, too, then where can we file a bug report? billg@microsoft.com ? In other words, you might as well shout the report at the statue of David and hope it gets fixed :-( By way of proof, you can recreate the bug exactly using Wordpad. Type a single word, and check the are no blank lines (try arrowing down). Then hit Ctrl-C and the mystery extra char also gets selected. Paste it into pgAdmin's grid or Wordpad, and the newline will appear. All is not necessarily lost however - it strike me that we might be able to use the STC control instead of a rich textbox (thats the one we use for the SQL input fields). I'll look into it.... /D
Dave Page wrote: > All is not necessarily lost however - it strike me that we might be able > to use the STC control instead of a rich textbox (thats the one we use > for the SQL input fields). I'll look into it.... Unfortunately that doesn't seem to be feasible :-( Regards, Dave.
dpage@postgresql.org wrote: > Dave Page wrote: > >> All is not necessarily lost however - it strike me that we might be able >> to use the STC control instead of a rich textbox (thats the one we use >> for the SQL input fields). I'll look into it.... >> > > Unfortunately that doesn't seem to be feasible :-( > Thanks for trying, though! Regards Erwin