Thanks, patch applied. On Fri, Dec 9, 2016 at 1:59 PM, Akshay Joshi <akshay.jo...@enterprisedb.com> wrote:
> Hi Dave > > I have tried to get the width of the content but we are sending complete > data as collection to the SlickGrid. We will have to fetch the content of > each column and figure out the maximum length for that column by iterating > all the rows is too expensive. Apart from that to set the width in 'ch' we > will have to do it using css. With current implementation we are setting > the column option of the SlickGrid from javascript code. > > I have fixed this issue by setting the width of the columns based on data > type. I have set the width of boolean column to 60, all the > numeric/integer columns to 80 and for all other data types it is 20% of the > container width as 33% is too wide. Attached is the patch file, please > review it and let me know the review comments. > > On Fri, Dec 9, 2016 at 2:15 PM, Akshay Joshi < > akshay.jo...@enterprisedb.com> wrote: > >> Hi Dave >> >> On Fri, Oct 28, 2016 at 8:43 PM, Dave Page <dp...@pgadmin.org> wrote: >> >>> Hi >>> >>> On Fri, Oct 28, 2016 at 7:04 AM, Akshay Joshi < >>> akshay.jo...@enterprisedb.com> wrote: >>> >>>> Hi All >>>> >>>> Please find the attached patch to fix the RM #1789 Column width of data >>>> output panel should fit to data (as pgAdmin III). >>>> >>>> >>> This doesn't seem to work as expected: >>> >>> 1) The columns are resized, but equally. For example, given a query of >>> "SELECT * FROM pg_description", I would expect the first 3 columns to be >>> roughly the size they are without the patch, and the 4th column to be much >>> wider (in the ticket I suggested the width of the content, up to a maximum >>> of 33% of the width of the container). >>> >> >> We will have to set the width of columns depending on the *data type* >> for example all the numeric/integers we can set the column width = 80(may >> change), for boolean we can set it up to 50, for strings/timestamps/bytea >> /jsonb/.. we can set the width equal to 33% of the width of the >> container. I am not sure how we can find the width of the content. Please >> suggest is this approach looks good to you? >> >>> >>> 2) After executing a second query (which works as expected), further >>> queries fail to update the resultset. I was selecting from pg_class, >>> pg_attribute and pg_description, and repeatedly found (no matter what order >>> I queried each table), only the first two queries returned the expected >>> results. The third and subsequent always re-displayed the results of the >>> second query. Reverting the patch caused this issue to go away. >>> >> >> There was an error in background due to "*forceFitColumns = true*" >> option of the SlickGrid. I have remove that logic. >> >>> >>> -- >>> Dave Page >>> Blog: http://pgsnake.blogspot.com >>> Twitter: @pgsnake >>> >>> EnterpriseDB UK: http://www.enterprisedb.com >>> The Enterprise PostgreSQL Company >>> >> >> >> >> -- >> *Akshay Joshi* >> *Principal Software Engineer * >> >> >> >> *Phone: +91 20-3058-9517 <+91%2020%203058%209517>Mobile: +91 976-788-8246* >> > > > > -- > *Akshay Joshi* > *Principal Software Engineer * > > > > *Phone: +91 20-3058-9517 <+91%2020%203058%209517>Mobile: +91 976-788-8246* > -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
