Re: public schema not prefixed / copy + paste adds newline

On Jul 19, 4:53 pm, dp(dot)(dot)(dot)(at)postgresql(dot)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