Re: [pgadmin-support] NULL vs empty string in Query Tool
Chris Reigrut wrote:
> Is there any way to distinguish between an empty string ('') and a
NULL
> string value in the query tool?
I'd like to resurrect this question from a while ago. It does not seem
like it got any response. It would be great if pgAdmin's Query Tool had
a setting similar to psql's "\pset NULL" formatting option. It is very
easy to confuse the two and most query tools that I know of allow for
that.
George
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
[pgadmin-support] pointing pgAdmin III to a pre-8.1 help file
This is sort of an enhancement idea: currently if you run pgAdmin III its help files by default assume an 8.1 PG, which is a bit confusing, because one could be (as I am) administering/connecting to some pre-8.1 servers through pgAdmin III. It would be quite nice if the help files were either sensitive to the version of the underlying server (when the ? is pressed) or at least allowed for choosing which help-set to use when help is invoked (just add nodes for "PostgreSQL 8.0.5 Documentation", etc.) I think the best one can currently do (and please correct me if I am wrong) is to swap the *.CHM from an older version of pgAdmin (but then you lose the 8.1 help, so not really good for a mixed-version environment). George ---(end of broadcast)--- TIP 6: explain analyze is your friend
[pgadmin-support] pgAdmin corrupts pgpass.conf on windows
Is this a known problem? Is there a fix for it? It seems that pgAdmin (v.1.4.1 for sure, but I think some prior versions as well) on Windows corrupt the pgpass.conf file by deleting existing entries and adding "garbage" ones. This is not a huge problem for pgAdmin itself, although this presents itself as pgAdmin "forgetting" the password that it had previously remembered for you and making you type it again -- a minor annoyance. Where it ends up being really disruptive for me is that it trips my psql runs and various scripts that rely on my passwords being set. Are there any plans to fix the problem? Is it at all possible to change the behavior so that psql and pgAdmin to not rely on the same pgpass.conf? Is there any configuration variable that I can set for pgAdmin to make it point to a different pgpass.conf As an example, below is my actual pgpass.conf file as of today after a few battles between pgAdmin and psql for control over it (I have changed usernames and passwords to protect the innocent). And no, I do not have a server named "7" -- these are just truncated garbage lines inserted by pgAdmin. the sequences of #s are places where pgAdmin has deleted the lines after the comment, so it used to look like this: # servername1:5432:*:moo:goo servername1:5432:*:gai:pan # servername2:5432:*:moo:goo servername2:5432:*:gai:pan and pgAdmin made it look like this: # # Here are the complete pgpass file contents: - # # # localhost:5432:*:foo:foo # dev07:5432:*:moo:moo dev07:5432:*:foo:foo # # # 192.168.68.67:5432:*:foo:foo # localhost:5435:*:foo:foo # localhost:5436:*:foo:foo # localhost:5437:*:moo:moo localhost:5437:*:foo:foo # 7:*:foo:foo # 7:*:foo:foo # :foo # 7:*:foo:foo # 7:*:foo:foo # 192.168.68.65:5432:*:foo:foo dev03:5432:*:moo:moo res:foo dev03:5432:*:moo:moo res:foo dev03:5432:*:moo:moo es dev03:5432:*:moo:moo localhost:5435:*:moo:moo localhost:5435:*:moo:moo localhost:5435:*:moo:moo - ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgadmin-support] pgAdmin corrupts pgpass.conf on windows
> If you remove your file altogether and just let pgAdmin manage it > itself, does it then corrupt it as well? I tried that for a bit a while ago and I did not see any corruption, but I am not sure my tests were exhaustive. The problem is that that is really not a solution for me because I want to be able to have many more server/port/user/password combinations stored in there for psql/script purposes than the few that I need for pgAdmin. For a while I thought that my comment lines (starting with #) were confusing pgAdmin but it seems to do the rearranging with or without comments in there. Another workaround would be to never let pgAdmin store passwords -- that does help although pgAdmin still seems to touch the file (it does not mess it up as bad). If I have to I would take this approach because for my purposes psql scripts/pg_dump/pg_restore are primary to pgAdmin. I was just hoping for a way for the two to coexist peacefully (and also to be able to reuse my Linux .pgpass on Windows). > What characterset/locale etc. does your copy of Windows run in? Don't know which of the many locale-related Windows settings you are interested in but this is a Win XP Pro ver 2002 SP2 with the most standard default English/US settings that have not been messed with since it came from the factory. Under "Regional and Language Options" under "Standards and formats" it says "English (United States)", under Location it says "United States", under "Language for non-Unicode programs" it says "English (United States)", etc. Let me know if there is some registry or env variable that would be helpful. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgadmin-support] autovacuum?
> What else should I do to make it happen? > > If you look in your logs, you should see something like: > May 17 13:24:49 fritz postgres[13852]: [3-1] LOG: > autovacuum: processing database "postgres" Not sure why this thread is on pgadmin-support (general would be a better place for it), but do note that as far as I know the log lines you are referring to only indicate that autovacuum is processing the database to see if it needs vacuuming -- there may not be any actual vacuuming going on, because of, for example, your entries in the pg_autovacuum system table. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[pgadmin-support] pgadmin clipboard lost on shutdown
this is somewhat minor: most windows applications seem to retain the clipboard after the application is closed. pgadmin does not, which seems non-standard. i have had a couple of "oops" moments and lost work because of this. i have seen this on pgadmin III running on windows 1.4.1 george ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[pgadmin-support] focus/cursor issue with 1.4.3 query UI
A small but very annoying bug in pgAdmin 1.4.3 on Windows: -- in the query select some text with the mouse; -- now click somewhere on the selected text--as expected the selection is lost--your cursor is somewhere in the middle of the previously highlighted text; -- now try to move your cursor with the up/down/left/right keys -nothing happens -- click again--now you can move your cursor with the mouse pgAdmin 1.4.2 definitely does not have this problem. I think Dave Page knows about it, but just in case it fell through the cracks. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-support] pgAdmin 1.4.3 bug with delete button in win32
the behavior described by jl definitely happens to me too on a straight out of the box, freshly installed windows xp sp2 with an american english untweaked keyboard (this is about as stock as it gets--a brand new computer, not much installed yet in terms of other software). also as described by heiko selber the data edit functionality seems to be completely non-working. george ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgadmin-support] pgAdmin 1.4.3 bug with delete button in win32 & OTHER
> > also as described by heiko selber the data edit > > functionality seems to > > be completely non-working. > > *Completely non-working*? You mean you cannot edit data and save it > even if you don't hit the delete key? You cannot delete rows by > selecting the row and using the delete key or button? sorry, i should have tried more scenarios and been more specific. i don't use this part of the application at all, so don't have much by way of volume of observations. here's what i see: 1. if only one cell is selected (but not in cell-edit mode) and i press DELETE i get a confirmation dialog, saying "yes" to that does not do anything -- this is what i was referring to. this is bad. 2. if i click on a rownumber (highlight a whole row) and press DELETE i get a confirmation dialog and the row gets deleted. this is good. 3. if i get into edit mode on a cell (press F2, or double click) i can edit (except for the delete key bug) and the changes get saved. 4. if in the above scenario (3) i have pressed DELETE at any time F2, the UP, DOWN, LEFT, RIGHT keys stop working until i click someplace. 5. if i highlight a COLUMN and press DELETE, it asks me about deleting a ROW, but of course nothing happens. now that i am looking at that grid in detail here are a few other bugs/questions/enhancement ideas: a. click on a row number and select a whole row (as in (1) above), now holding the SHIFT key start pressing the DOWN key -- you would expect subsequent rows to be fully highlighted, instead only one column of cells of those rows are highlighted (the cells below the cell that was highlighted before you selected the whole row), resulting in a funky T- or L-shaped pattern. not sure what pressing DELETE should do after that -- the confirmation dialog comes up but nothing really happens when you say "yes" -- i guess this is behavior similar to (1). b. how can one insert a tab character in a cell? by analogy with a newline (CTRL+ENTER) i would have expected CTRL+TAB to work, but that just moves you to the next cell. c. pressing CTRL+SPACE on a cell highlights the cell and makes the save icon enabled in the toolbar even though no visible data change is observed. d. double-clicking the column separator in the column header sizes the column to the width of the HEADER, ignoring the width of the data, this is behavior that is the exact opposite of the behavior of the data grid in the query tool (there double-clicking sizes the columns to the width of the data ignoring the header/column name width). i personally like neither behavior--it would be best if it got sized to a width that accomodates BOTH the header and the data width. e. double clicking a column separator sizes the column back to the single row height -- sizing to the height of the tallest entry (if you have multi-line data in any of that row's cells) would probably be a more standard behavior. f. when entering a new row of data and suing TAB to move between columns there is no per-cell validation (which happens when you press ENTER after each cell), so if you have messed up something (say, entered two characters in a char(1) field all your data entry gets wiped out once you have completed a row -- would be nice if you just got asked to edit your faulty entry rather than having to start from scratch again. actually it is not even clear the data is completely lost (maybe it is somewhere in the background, because clicking on the * row sometimes gives you errors about other fields that violate constraints, etc. -- this is hard to fully describe in a few sentences). all for now. don't mean to be too critical/overwhelming, just thought i'd put down in writing what i saw. george ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgadmin-support] pgAdmin 1.4.3 bug with delete button in win32 & OTHER
ERRATA: substitute ROW for COLUMN in (e): e. double clicking a ROW separator sizes the ROW back to the single row height -- sizing to the height of the tallest entry (if you have multi-line data in any of that row's cells) would probably be a more standard behavior. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > George Pavlov > Sent: Thursday, August 03, 2006 11:47 AM > To: pgadmin-support@postgresql.org > Subject: Re: [pgadmin-support] pgAdmin 1.4.3 bug with delete > button in win32 & OTHER > > > > also as described by heiko selber the data edit > functionality seems > > > to be completely non-working. > > > > *Completely non-working*? You mean you cannot edit data and save it > > even if you don't hit the delete key? You cannot delete rows by > > selecting the row and using the delete key or button? > > sorry, i should have tried more scenarios and been more > specific. i don't use this part of the application at all, so > don't have much by way of volume of observations. here's what i see: > > 1. if only one cell is selected (but not in cell-edit mode) > and i press DELETE i get a confirmation dialog, saying "yes" > to that does not do anything -- this is what i was referring > to. this is bad. > > 2. if i click on a rownumber (highlight a whole row) and > press DELETE i get a confirmation dialog and the row gets > deleted. this is good. > > 3. if i get into edit mode on a cell (press F2, or double > click) i can edit (except for the delete key bug) and the > changes get saved. > > 4. if in the above scenario (3) i have pressed DELETE at any > time F2, the UP, DOWN, LEFT, RIGHT keys stop working until i > click someplace. > > 5. if i highlight a COLUMN and press DELETE, it asks me about > deleting a ROW, but of course nothing happens. > > > now that i am looking at that grid in detail here are a few > other bugs/questions/enhancement ideas: > > a. click on a row number and select a whole row (as in (1) > above), now holding the SHIFT key start pressing the DOWN key > -- you would expect subsequent rows to be fully highlighted, > instead only one column of cells of those rows are > highlighted (the cells below the cell that was highlighted > before you selected the whole row), resulting in a funky T- > or L-shaped pattern. not sure what pressing DELETE should do > after that > -- the confirmation dialog comes up but nothing really > happens when you say "yes" -- i guess this is behavior similar to (1). > > b. how can one insert a tab character in a cell? by analogy > with a newline (CTRL+ENTER) i would have expected CTRL+TAB to > work, but that just moves you to the next cell. > > c. pressing CTRL+SPACE on a cell highlights the cell and > makes the save icon enabled in the toolbar even though no > visible data change is observed. > > d. double-clicking the column separator in the column header > sizes the column to the width of the HEADER, ignoring the > width of the data, this is behavior that is the exact > opposite of the behavior of the data grid in the query tool > (there double-clicking sizes the columns to the width of the > data ignoring the header/column name width). i personally > like neither behavior--it would be best if it got sized to a > width that accomodates BOTH the header and the data width. > > e. double clicking a column separator sizes the column back > to the single row height -- sizing to the height of the > tallest entry (if you have multi-line data in any of that > row's cells) would probably be a more standard behavior. > > f. when entering a new row of data and suing TAB to move > between columns there is no per-cell validation (which > happens when you press ENTER after each cell), so if you have > messed up something (say, entered two characters in a char(1) > field all your data entry gets wiped out once you have > completed a row -- would be nice if you just got asked to > edit your faulty entry rather than having to start from scratch again. > actually it is not even clear the data is completely lost > (maybe it is somewhere in the background, because clicking on > the * row sometimes gives you errors about other fields that > violate constraints, etc. -- this is hard to fully describe > in a few sentences). > > all for now. don't mean to be too critical/overwhelming, just > thought i'd put down in writing what i saw. > > george > > > ---(end of > broadcast)--- > TIP 5: don't forget to increase your free space map settings > ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[pgadmin-support] pgAdmin 1.6 Beta 2 query crashes on windows
PgAdmin III Query 1.6 Beta 2 is pretty unusable to me (WinXP SP2, stock
US install) -- it crashes fairly regularly upon query submission and I
end up losing a lot of my edits. FWIW, in 99% of the times I submit
queries by highlighting using keyboard + F5. No particular pattern of
usage causes this, just some up and down in the query edit pane, maybe
some clicking in the result-set grid, and query submission. Usually it
happens several queries into my interaction with pgAdmin (it has NEVER
happened on the first query submitted). Not sure what else to report,
but I will be reverting back to the old version because I lose too much
work from crashes this way.
I have saved some of the Windows output ("Do you want to send your
information to MS?" dialogs) if anyone thinks they may be useful I can
email.
George
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [pgadmin-support] pgAdmin 1.6 Beta 2 query crashes on windows
Dave,
It still crashes upon query submittal. I see no difference from beta2 in
this aspect.
George
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Dave Page
> Sent: Friday, October 13, 2006 12:14 AM
> To: George Pavlov; pgadmin-support@postgresql.org
> Subject: Re: [pgadmin-support] pgAdmin 1.6 Beta 2 query
> crashes on windows
>
>
>
> > -Original Message-
> > From: George Pavlov [mailto:[EMAIL PROTECTED]
> > Sent: 12 October 2006 22:23
> > To: pgadmin-support@postgresql.org
> > Cc: Dave Page
> > Subject: pgAdmin 1.6 Beta 2 query crashes on windows
> >
> > PgAdmin III Query 1.6 Beta 2 is pretty unusable to me (WinXP
> > SP2, stock
> > US install) -- it crashes fairly regularly upon query
> submission and I
> > end up losing a lot of my edits. FWIW, in 99% of the times I submit
> > queries by highlighting using keyboard + F5. No particular
> pattern of
> > usage causes this, just some up and down in the query edit
> pane, maybe
> > some clicking in the result-set grid, and query submission.
> Usually it
> > happens several queries into my interaction with pgAdmin
> (it has NEVER
> > happened on the first query submitted). Not sure what else
> to report,
> > but I will be reverting back to the old version because I
> > lose too much
> > work from crashes this way.
> >
> > I have saved some of the Windows output ("Do you want to send your
> > information to MS?" dialogs) if anyone thinks they may be
> useful I can
> > email.
>
> George,
>
> Please try beta 3
> (http://developer.postgresql.org/ftpsite/pgadmin3/release/v1.6
> .0-beta3/)
> . I've made some changes that will hopefully solve this issue.
>
> Regards, Dave.
>
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
[pgadmin-support] pgAdmin 1.6 beta password issues
I had sent a version of this bug report to Dave Page directly a few days ago, but let me clarify and do it through the forum. It seems that pgAdmin 1.6 beta on windows suffers from some old password issues -- one that is consistent, the other one I cannot reproduce reliably: (a) the intermittent/not reproducible one -- the pgpass file gets corrupted eventually and I start seeing lines like this: bcde alhost:5446:*:mno:vwxyz where "abcde" is a user name and "vwxyz" is a password, so the first of the above lines has a chopped off user name in the first position (where the server name should be) and a bunch of blanks and the second line looks almost OK except that the server name is chopped off. This happens with ONLY pgAdmin (no psql) connecting from this Windows machine. (b) connecting the last server defined in the pgAdmin tree always starts off with an error. To reproduce: 1. start with a cleaned-up pgpass file (remove all weirdnesses as described in (a) 2. make sure the last server in your tree has a saved password (save a password through the server definition in pgAdmin and verify that the pgpass file looks correct). 3. close and reopen pgAdmin 4. double click on the last node in the server tree (in order to open a connection to that server) 5. get error pop-up "An error has occurred: Error connecting to the server: fe_sendauth: no password supplied" 6. close the error window 7. double click on same node again 8. now you get the connect to server dialog with the "store password" checkbox on (so it knows that the setting is to have it saved) but no password in the textbox 9. type the password 10. now you can connect As you are doing all this monitor the pgpass file and note that it is not changing at all: the line for that server was there at step 3 and is there after step 10 (the file timestamp does change [at step 10], but none of its contents are changed). ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-support] pgAdmin preBeta4 - results
pgAdmin v.1.6 beta 3 (5508:5517) has been good for me so far. all the issues i had with previous versions seem fixed and i can't find new ones ;-) good job, dave! i am still a bit bummed about two of my biggest pgAdmin pet peeves not being resolved (no distinction between a NULL and a zero-length string in the grids and the loss of clipboard after closing the app), but we will wait patiently! > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Harald Armin Massa > Sent: Tuesday, October 24, 2006 12:13 AM > To: Dave Page; pgAdmin Support > Subject: [pgadmin-support] pgAdmin preBeta4 - results > > Hello Dave, > > I was using that .exe from yesterday intensly. > > There was only one "stuck" situation, and that was a long > running query, and in the middle of the process a virus > scanner started to scan. So far from my side: good bugfixing! > > > One very frustrating habbit was the resizing of the columns > of the data grid: I could drag them to every width; but with > the next run of the query they moved back to standard. I am > not sure if this qualifies as "bug", or rather "feature > request", as "do not resize column-width unless types or > numbers of query result columns change" > > Thansk for all that good work, > > Harald > > > -- > GHUM Harald Massa > persuadere et programmare > Harald Armin Massa > Reinsburgstraße 202b > 70197 Stuttgart > 0173/9409607 > - > Python: the only language with more web frameworks than keywords. > ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-support] pgAdmin preBeta4 - results
> I grant you that I don't think the query grid does > differentiate - I'll bung that on the roadmap. i did mean the query grid (i hardly ever use the edit grid). i thought it was on the roadmap: http://archives.postgresql.org/pgadmin-support/2006-01/msg00013.php > > and the loss of clipboard after closing the app), but we > will wait patiently! > > I didn't realise it did lose it. I'll add that too. http://archives.postgresql.org/pgadmin-support/2006-05/msg00065.php where is this "roadmap" anyway? might be good to review for my own edification and to adjust expectations. thanks! george ---(end of broadcast)--- TIP 6: explain analyze is your friend
[pgadmin-support] no error message on lost connection (regression from 1.4)
I think Dave fixed one of the cases that caused this a few revs ago, but another one still remains. Steps to reproduce: In pgAdmin 1.4.2: * connect to a configured DB running on a networked machine * open query * issue a query * observe result set * disconnect your network connection (plug out and back in your cable, e.g.) * issue the query again * get meaningful error message: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. In pgAdmin 1.6 RC1 (5574M): * repeat the exact same steps as above * get message ":" (just a colon) in the message window George ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[pgadmin-support] enhancement idea: re-establish lost connections?
Shouldn't it be fairly easy to make pgAdmin reconnect do servers it has lost its connection to? After all it has all the connection information (assuming password is saved) and could try to re-establish it? I personally use a laptop and often switch connections (wired LANs, wifi, cellular broadband) and find it a major drag having to reestablish all connections: go through all the dialogs for broken connections, close and reopen all query windows (I often have about half a dozen going), making sure unsaved ones are taken care of, reopen all query files (or cut and paste from "dead" windows, etc.) Thanks! George ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[pgadmin-support] renaming a DB through UI?
How is one (or is one) supposed to rename a DB through the pgAdmin UI? In 1.4.2 in the DB properties dialog the OK button becomes enabled if you changed the name in the dialog, but you get an error about renaming the current DB (there does not seem to be a way to not have that DB be your current DB). In 1.6 RC1, typing in a new name in the dialog does not enable the OK button and does not add the alter SQL to the SQL tab. I am wondering if this was a response to the 1.4.2 problem or if a bug. If it is a conscious change then graying the field out (as is done with the OID, tablespace, etc. fields) might be more appropriate otherwise the user is given mixed signals--he/she makes a change and nothing happens in response... And of course the big question is whether renaming through the UI should be supported. George ---(end of broadcast)--- TIP 6: explain analyze is your friend
[pgadmin-support] system object display option?
this might be a bug or me misunderstanding how things work (in which case please help). in pgadmin 1.6.* selecting view/system objects results in system objects (such as the information_schema and pg_catalog schemas) showing in the tree view. i am guessing that for 1.8 the equivalent functionality is under file/options/display. i have "show system objects in the treeview" checked and schemas is checked in the list of objects to display, but my information_schema and pg_catalog schemas are not showing (pg_toast and pg_temp_x are showing though). i am on 1.8.0 beta 5. george ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
