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



---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

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.

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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.

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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.

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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



---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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.

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq