Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d6fBw-0006xC-SW for pgadmin-hackers@arkaria.postgresql.org; Fri, 05 May 2017 15:30:49 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1d6fBw-0005S5-En for pgadmin-hackers@arkaria.postgresql.org; Fri, 05 May 2017 15:30:48 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1d6fBu-0005Ml-Gt for pgadmin-hackers@postgresql.org; Fri, 05 May 2017 15:30:46 +0000 Received: from mail-ua0-x235.google.com ([2607:f8b0:400c:c08::235]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1d6fBp-0007AW-4N for pgadmin-hackers@postgresql.org; Fri, 05 May 2017 15:30:45 +0000 Received: by mail-ua0-x235.google.com with SMTP id e55so5737967uaa.2 for ; Fri, 05 May 2017 08:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pivotal-io.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tohSLO3xhk5Zhzq9FW4BDRv7TAd23VDO8I5rj3sKuUs=; b=KJqrN3O416tYnD3VdaQXfzte9yR9A45IIMVYXhAGhO3iy3QMFZ9S8WdPQFitzuOg0P Pa1M6Zk6LhH0bYtlUfSc4aTEHEsVJUmJJ+nG5wMEOMSSijRrEVCl1jmbAqXF725CYgA1 EcOL8IwrktAOrzAWf2O0BM0Cr8/vzPGGjSKjxLTECT4JdeNFwYOH5jsWbkUwsxQ4fFU/ wCNptGyj7DJ4+SFnt6J4DstbohvsYJW2Ai+e1vBSaRZoYDm3UU9/9eVkfBr+59mXAe3S qC47xiYoLZCBX0Di2QGy8pZ/CK0AnXWyZUWvpYyS51ob4V0oYr/3cFqbdiEl3aY0djp+ 3Nig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tohSLO3xhk5Zhzq9FW4BDRv7TAd23VDO8I5rj3sKuUs=; b=Fqw6ydPXON3dRMIbkXd9RV2/PaIvmEyfNXsKzvCbYJC9l/dgnKaVj8gYfWLT68b/4L +tn/fFmIsAbn1ZMOCxT06AIlQ9SF8tgvon7PO0VKGDN4vXBWfPsztXg7zVw7lU4eBfbn vgFnwK1f7Ahk3w08m6UCfR2ZolzOqSD3YMcOlk5LOHKOWk3wkrtNE932n+KYQVhPI7Ze HwX/l91R4tms2pW7KbeRrVpsbAyxuGc2OnPxFZh6+HXYBE4VVcuegXeHCRhYpBgU5Z8y UcxWwOhfd6sC5/TfB/j8AE8GMcodWDRzXWuqmGws2AOkeVMUSeEgJGO5VvydViu5GfaW UDKQ== X-Gm-Message-State: AN3rC/4lUp1fTHU3lw6fXlb59SmVYSXA+7+iLm6IKzkrtaeoim74IKWE qRF9uNJBiiXauv40aD/VUladUsiKXAPD X-Received: by 10.159.40.194 with SMTP id d60mr7197478uad.105.1493998239150; Fri, 05 May 2017 08:30:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.10.199 with HTTP; Fri, 5 May 2017 08:30:38 -0700 (PDT) In-Reply-To: References: From: Joao Pedro De Almeida Pereira Date: Fri, 5 May 2017 11:30:38 -0400 Message-ID: Subject: Re: [pgAdmin4][Patch]: Fixed RM #2315 : Sorting by size is broken To: Khushboo Vashi Cc: Dave Page , pgadmin-hackers , Ashesh Vashi , George Gelashvili Content-Type: multipart/alternative; boundary=94eb2c1245be5720cf054ec89257 X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgadmin-hackers Precedence: bulk Sender: pgadmin-hackers-owner@postgresql.org --94eb2c1245be5720cf054ec89257 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Khushboo, We looked at your updated patch: - the tests look good! - there's a small comment header change needed in size_prettify_spec - it looks like the previous and new functions have different behaviors (where the new behavior changes units on 10000 of the lower unit, a 9999GB) - We should clarify that in size_prettify, we were mostly talking about name readability in your first patch, and that the original structure was better (especially the sizes array) At first glance, the new sizePrettify appears to behave like a for loop, so that might be the simplest refactor. Thanks, Joao and George On Thu, May 4, 2017 at 5:02 AM, Khushboo Vashi < khushboo.vashi@enterprisedb.com> wrote: > Hi, > > Please find the attached updated patch. > > Thanks, > Khushboo > > On Fri, Apr 28, 2017 at 7:58 PM, Matthew Kleiman > wrote: > >> Hi Khushboo, >> >> That sounds good. Sorry if we weren't clear at first. >> >> Have a good holiday weekend! >> >> Sarah & Matt >> >> >> On Fri, Apr 28, 2017 at 4:35 AM, Khushboo Vashi < >> khushboo.vashi@enterprisedb.com> wrote: >> >>> Hi Sarah, >>> >>> On Thu, Apr 27, 2017 at 7:38 PM, Sarah McAlear >>> wrote: >>> >>>> Hi Kushboo! >>>> >>>> We understand your point, but we believe that relying on 2 independent >>>> functions to deliver the same formatting can become a problem if the P= G >>>> function changes. Our suggestion is to use a single function in our >>>> javascript code to do this formatting. >>>> >>>> It seems reasonable to me and I am going to use a single javascript >>> function which will support PB also (as per Dave we should add support = till >>> PB) . >>> >>>> If the community believes we can live with this risk, let's move >>>> forward. >>>> >>>> Thanks! >>>> Sarah & Joao >>>> >>>> On Thu, Apr 27, 2017 at 1:50 AM, Khushboo Vashi < >>>> khushboo.vashi@enterprisedb.com> wrote: >>>> >>>>> Hi Joao & Sarah, >>>>> >>>>> On Wed, Apr 26, 2017 at 8:46 PM, Joao Pedro De Almeida Pereira < >>>>> jdealmeidapereira@pivotal.io> wrote: >>>>> >>>>>> Hi Khushboo! >>>>>> >>>>>> Thanks for your reply! >>>>>> >>>>>> >>>>>>> *SQL Files:* >>>>>>>> >>>>>>>> - Is there a way to avoid conditionals here? >>>>>>>> >>>>>>>> >>>>>>>> - Maybe we can use the same javascript function to prettify all >>>>>>>> the sizes >>>>>>>> >>>>>>>> >>>>>>>> In case of collection node (ex: Databases), I have implemented thi= s >>>>>>>> functionality via putting a formatter for a back-grid column. So, = it is >>>>>>>> applicable for the entire column not for the individual cell. To a= pply the >>>>>>>> javascript function on a single cell for the column (string column= ), first >>>>>>>> we need to identify that cell and then apply the function, I think= this is >>>>>>>> overhead. Just to avoid conditional sql template I would not prefe= r this >>>>>>>> approach. >>>>>>> >>>>>>> >>>>>> We are not totally sure we understood what you meant on the previous >>>>>> statement. Are you saying that the conditionals in SQL are used to e= nsure >>>>>> that we can apply a javascript function at column level instead of c= ell >>>>>> level? >>>>>> >>>>>> Correct. >>>>> >>>>>> Our concern is that the templates are being made more complex and >>>>>> inconsistencies are introduced in the code and the UI. >>>>>> >>>>> >>>>> Inconsistencies in the UI can be avoided through making the >>>>> size_formatter same as pg_size_pretty function which I will implement= . >>>>> I have checked the pg_size_pretty function code and it supports till >>>>> TB format, so I think we should keep till TB only. >>>>> >>>>> In this particular example, we are allowing the backend to respond >>>>>> sometimes with prettified data and sometimes without it, so at UI le= vel we >>>>>> will have inconsistencies between screens or more complex Javascript= code >>>>>> to support sometimes prettifying and sometimes not prettify the same >>>>>> fields. >>>>>> >>>>>> We have separate logic for collection and single node in >>>>> statistics.js and we are using javascript code for prettifying only f= or >>>>> collection node. >>>>> >>>>> >>>>>> What we were thinking was to maybe not specify on the SQL level and >>>>>> have the same format for "Size" everywhere in the UI. >>>>>> >>>>>> >>>>> Here our main concern is inconsistency in "Size" format in the UI tha= t >>>>> can be avoided as I said earlier. >>>>> We are using pg_size_pretty function for different fields like Size, >>>>> Index Size, Table space size, Tuple length, Size of Temporary files i= n >>>>> different modules and some of them are cell level and we don't requir= e to >>>>> put overhead on cell level fields as sorting is not required for indi= vidual >>>>> node statistics. >>>>> >>>>> >>>>> >>>>>> Thanks >>>>>> Joao & Sarah >>>>>> >>>>>> On Tue, Apr 25, 2017 at 11:48 PM, Khushboo Vashi < >>>>>> khushboo.vashi@enterprisedb.com> wrote: >>>>>> >>>>>>> Hi Joao & Sarah, >>>>>>> >>>>>>> Thanks for reviewing the patch. >>>>>>> >>>>>>> On Tue, Apr 25, 2017 at 8:34 PM, Joao Pedro De Almeida Pereira < >>>>>>> jdealmeidapereira@pivotal.io> wrote: >>>>>>> >>>>>>>> Hello Khushboo, >>>>>>>> >>>>>>>> We reviewed the this patch and have some suggestions: >>>>>>>> >>>>>>>> *Python:* >>>>>>>> =E2=80=8B >>>>>>>> The functionality for adding the "can_prettify" is repeated in >>>>>>>> multiple places. Maybe this could be extracted into a function. >>>>>>>> >>>>>>>> When I have implemented this, my first thought is exactly same as >>>>>>> you suggested but while looking at the code I felt its not a good = idea to >>>>>>> have a function. In case of a function, we need to pass the whole >>>>>>> result-set as well as the list of fields which we need to be pretti= fied. >>>>>>> So, only for 2 lines, I didn't find any reason to make a function. >>>>>>> >>>>>>>> *Javascript:* >>>>>>>> =E2=80=8B >>>>>>>> >>>>>>>> - The class Backgrid.SizeFormatter doesn't seem to have any >>>>>>>> tests. >>>>>>>> >>>>>>>> >>>>>>>> Sure, will do. >>>>>>> >>>>>>>> >>>>>>>> - The function pg_size_pretty displays bytes and Kilobytes >>>>>>>> differently. >>>>>>>> - Is it possible to add PB as well? >>>>>>>> >>>>>>>> Will check and add PB. >>>>>>> >>>>>>>> >>>>>>>> - >>>>>>>> - The function is a little bit hard to read, is it possible to >>>>>>>> refactor using private functions like: >>>>>>>> >>>>>>>> Will make it more readable. >>>>>>> >>>>>>>> fromRaw: function (rawData, model) { >>>>>>>> var unitIdx =3D findDataUnitIndex(rawData); >>>>>>>> if (unitIdx =3D=3D 0) { >>>>>>>> return rawData + ' ' + this.dataUnits[i]; >>>>>>>> } >>>>>>>> return formatOutput(rawData, unitIdx); >>>>>>>> }, >>>>>>>> >>>>>>>> =E2=80=8B >>>>>>>> >>>>>>>> >>>>>>>> - In statistics.js:326 we believe it would make the code more >>>>>>>> readable if we change the variable "c" to "rawColumn" and "col"= to "column". >>>>>>>> >>>>>>>> >>>>>>>> I will change the variable name from "c" to "rawColumn" but I >>>>>>> think "col" is appropriate as we already have columns variable and = anyone >>>>>>> can confuse while reading the code (for columns and column). >>>>>>> >>>>>>>> >>>>>>>> *SQL Files:* >>>>>>>> =E2=80=8B >>>>>>>> >>>>>>>> - Is there a way to avoid conditionals here? >>>>>>>> - Maybe we can use the same javascript function to prettify all >>>>>>>> the sizes >>>>>>>> >>>>>>>> >>>>>>>> In case of collection node (ex: Databases), I have implemented thi= s >>>>>>> functionality via putting a formatter for a back-grid column. So, i= t is >>>>>>> applicable for the entire column not for the individual cell. To ap= ply the >>>>>>> javascript function on a single cell for the column (string column)= , first >>>>>>> we need to identify that cell and then apply the function, I think = this is >>>>>>> overhead. Just to avoid conditional sql template I would not prefer= this >>>>>>> approach. >>>>>>> >>>>>>>> >>>>>>>> Visually we saw a difference between "Databases" statistics and a >>>>>>>> specific database statistics. In "Databases" statistics the "Size"= is "7.4 >>>>>>>> MB" but when you are in the specific database the "Size" is "7420 = kB". >>>>>>>> Is this the intended behavior? >>>>>>>> >>>>>>>> Only for the Databases (collection node), the client side >>>>>>> functionality is implemented not for individual node , so this beha= viour is >>>>>>> different. For the individual node still, we are using pg_size_pret= ty >>>>>>> function >>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>>> Thanks >>>>>>>> Joao & Sarah >>>>>>>> >>>>>>>> On Tue, Apr 25, 2017 at 7:58 AM, Dave Page >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Ashesh, can you review/commit this please? >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>> On Tue, Apr 25, 2017 at 10:18 AM, Khushboo Vashi < >>>>>>>>> khushboo.vashi@enterprisedb.com> wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Fixed RM #2315 : Sorting by size is broken. >>>>>>>>>> >>>>>>>>>> Removed the pg_size_pretty function from query for the collectio= n >>>>>>>>>> and introduced the client side function to convert size into hum= an readable >>>>>>>>>> format. So, the sorting issue is fixed as the algorithm will get= the actual >>>>>>>>>> value of size instead of formatted value. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Khushboo >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Sent via pgadmin-hackers mailing list ( >>>>>>>>>> pgadmin-hackers@postgresql.org) >>>>>>>>>> To make changes to your subscription: >>>>>>>>>> http://www.postgresql.org/mailpref/pgadmin-hackers >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Dave Page >>>>>>>>> Blog: http://pgsnake.blogspot.com >>>>>>>>> Twitter: @pgsnake >>>>>>>>> >>>>>>>>> EnterpriseDB UK: http://www.enterprisedb.com >>>>>>>>> The Enterprise PostgreSQL Company >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Thanks, >>>>>>> Khushboo >>>>>>> >>>>>> >>>>>> >>>>> Thanks, >>>>> Khushboo >>>>> >>>> >>>> >>> Thanks, >>> Khushboo >>> >> >> > > > -- > Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgadmin-hackers > > --94eb2c1245be5720cf054ec89257 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Khushboo,

We looked at your updated = patch:
- the tests look good!
- there's a small= comment header change needed in size_prettify_spec
- it looks li= ke the previous and new functions have different behaviors (where the new b= ehavior changes units on 10000 of the lower unit, a 9999GB)=C2=A0
- We should clarify that in size_prettify, we were mostly talking about na= me readability in your first patch, and that the original structure was bet= ter (especially the sizes array)
At first glance, the new sizePrettify a= ppears to behave like a for loop, so that might be the simplest refactor.

Thanks,
Joao and George



On Thu, May 4, 2017 at 5:02 AM, Khushboo Vashi <= ;khush= boo.vashi@enterprisedb.com> wrote:
Hi,

Please find the attached up= dated patch.

Thanks,
Khushboo

On Fri, Apr 28, 2017 at 7:58 PM, Matthew Kleiman <mkleiman@pivotal.io> wrote:
Hi Khushboo,

That sounds good. Sorry= if we weren't clear at first.=C2=A0

Have a go= od holiday weekend!

Sarah & Matt


On Fri, Apr 28, 201= 7 at 4:35 AM, Khushboo Vashi <khushboo.vashi@enterprisedb.c<= wbr>om> wrote:
Hi Sarah,

On Thu, Apr 27, 2017 at 7:38 PM, Sarah McAlear <= ;smcalear@pivotal.= io> wrote:
Hi Kushboo!

We understand your point, but we believe th= at relying on 2 independent functions to deliver the same formatting can be= come a problem if the PG function changes. Our suggestion is to use a singl= e function in our javascript code to do this formatting.=C2=A0
It seems reasonable to me and I am g= oing to use a single javascript function which will support PB also (as per= Dave we should add support till PB) .
If the community believes we can live with this ri= sk, let's move forward.

Thanks!
Sarah = & Joao
On Thu, Apr 27, 2017 at 1:50 AM, Khushboo Vash= i <khushboo.vashi@enterprisedb.com> wrote= :
Hi Joao & Sarah,

On Wed, Apr 26, 2017 at 8:46 PM, Joao Pedro De Almeida = Pereira <jdealmeidapereira@pivotal.io> wrote:
=
Hi Khushboo!

Thanks for your reply= !
=C2=A0<= /div>
SQL Files:
  • Is there a way to avoid conditiona= ls here?=C2=A0
  • Maybe we can use= the same javascript function to prettify all the sizes

In cas= e of collection node (ex: Databases), I have implemented this functionality= via putting a formatter for a back-grid column. So, it is applicable for t= he entire column not for the individual cell. To apply the javascript funct= ion on a single cell for the column (string column), first we need to ident= ify that cell and then apply the function, I think this is overhead. Just t= o avoid conditional sql template I would not prefer this approach.

We are not to= tally sure we understood what you meant on the previous statement. Are you = saying that the conditionals in SQL are used to ensure that we can apply a = javascript function at column level instead of cell level?=C2=A0
=
Correct.=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Our concern is that the templat= es are being made more complex and inconsistencies are introduced in the co= de and the UI.
=C2=A0
= Inconsistencies in the UI can be avoided through making the size_formatter = same as pg_size_pretty function which I will implement.
I hav= e checked the pg_size_pretty function code and it supports till TB format, = so I think we should keep till TB only.

In this particular example, we are allowing the = backend to respond sometimes with prettified data and sometimes without it,= so at UI level we will have inconsistencies between screens or more comple= x Javascript code to support sometimes prettifying and sometimes not pretti= fy the same fields.=C2=A0

We have separate logic for collection and single node in statistic= s.js and we are using javascript code for prettifying only for collection n= ode.
=C2=A0
What we were thinking was to maybe not specify on the SQL level and have= the same format for "Size" everywhere in the UI.=C2=A0
=C2=A0
Here our main concern is= inconsistency in "Size" format in the UI that can be avoided as = I said earlier.
We are using pg_size_pretty function for differen= t fields like Size, Index Size, Table space size, Tuple length, Size of Tem= porary files in different modules and some of them are cell level and we do= n't require to put overhead on cell level fields as sorting is not requ= ired for individual node statistics.
=C2=A0
=C2=A0
Thank= s
Joao & Sarah

On= Tue, Apr 25, 2017 at 11:48 PM, Khushboo Vashi <khushboo.vas= hi@enterprisedb.com> wrote:
Hi Joao & Sarah,

Thanks for reviewing the patch.

=
On Tue, Apr 25, 2017 at 8:34 PM, Joao Pedr= o De Almeida Pereira <jdealmeidapereira@pivotal.io> wrote:
Hello Khushboo,

We reviewed the this patch and have= some suggestions:

<= strong>Python:

=E2=80=8B
The functionality for adding the "can= _prettify" is repeated in multiple places. Maybe this could be extract= ed into a function.=C2=A0

When I have implemented this, my first thought is exactly same as you sug= gested but =C2=A0while looking at the code I felt its not a good idea to ha= ve a function. In case of a function, we need to pass the whole result-set = as well as the list of fields which we need to be prettified. So, only for = 2 lines, I didn't find any reason to make a function.
Javascript:

=E2=80=8B
  • The class=C2=A0Backgrid.SizeForm= atter doesn't seem to have any tests.=C2=A0
    =

Sure, will do= .=C2=A0
  • The function pg_size_pretty displays byt= es and Kilobytes differently.=C2=A0
  • Is it possible to add PB as= well?
Will check and add= PB.=C2=A0
  • The function is a little bit hard to re= ad, is it possible to refactor using private functions like:
Will make it more readable.
fromRaw:=
 function (rawData, model) {
   var unitIdx =3D findDataUnitIndex(rawData);
   if (unitIdx =3D=3D 0) {
      return rawData + ' ' + this.dataUnits[i];
   }
   return formatOutput(rawData, unitIdx);
},
=E2=80=8B=

  • In statistics.js:326 we believe it would= make the code more readable if we change the variable "c" to &qu= ot;rawColumn" and "col" to "column".
=

I will change the varia= ble name from =C2=A0"c" to =C2=A0"rawColumn" but I thin= k "col" is appropriate as we already have columns variable and an= yone can confuse while reading the code (for columns and column).
<= /div>

SQL Files:

=E2=80=8B
  • Is there a way to avoid condit= ionals here?=C2=A0
  • Maybe we can use the same javascript function to= prettify all the sizes

In case of collection node (ex: Databases), I have implemented th= is functionality via putting a formatter for a back-grid column. So, it is = applicable for the entire column not for the individual cell. To apply the = javascript function on a single cell for the column (string column), first = we need to identify that cell and then apply the function, I think this is = overhead. Just to avoid conditional sql template I would not prefer this ap= proach.

Visually we saw a difference= between "Databases" statistics and a specific database statistic= s. In "Databases" statistics the "Size" is "7.4 MB= " but when you are in the specific database the "Size" is &q= uot;7420 kB".
Is this the intended behavior?

Only for the Databases (collectio= n node), the client side functionality is implemented not for individual no= de , so this behaviour is different. For the individual node still, we are = using pg_size_pretty function
=C2=A0

Thanks
Joao & Sarah

On Tue, Apr 25, 2017 at 7:= 58 AM, Dave Page <dpage@pgadmin.org> wrote:
Ashesh, can you revie= w/commit this please?

Thanks.

On Tue, Apr 25, 2017 at 10:18 AM, Khushboo Vashi <= span dir=3D"ltr"><khushboo.vashi@enterprisedb.com> wrote:
Hi,

=
Fixed RM #2315 : Sorting by size is broken.

=
Removed the pg_size_pretty function from query for the collection and = introduced the client side function to convert size into human readable for= mat. So, the sorting issue is fixed as the algorithm will get the actual va= lue of size instead of formatted value.=C2=A0
=C2=A0

Thanks,
Khushboo




--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-ha= ckers




<= /div>--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsna= ke

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Co= mpany


= Thanks,
Khushboo


Thanks,
Khushboo


Thanks,
Khushboo




--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-ha= ckers


--94eb2c1245be5720cf054ec89257--