phppgadmin-devel — For Developers Only

Re: [ppa-dev] Releasing 5.1

[Jehan-Guillaume (i. de R. <io...@fr...>]

On 12/04/2013 15:57, Robert Treat wrote:
> On Fri, Apr 12, 2013 at 8:00 AM, Jehan-Guillaume (ioguix) de Rorthais
> <io...@fr...> wrote:
>> Hey,
>>
>>   23:36 < xzi11a> side note, i was looking at a patch from a while back,
>> i might commit it by end of weekend if we arent in release mode yet.
>>   23:37 < xzi11a> that said, i saw this:
>> http://sourceforge.net/blog/upgrades-april22/
>>   23:37 < xzi11a> we should probably try to release before april 22
>>
>> Agree, we should release before april 22th. As far as I know, we are not
>> yet in "release mode", so any kind of fix or feature is still welcome.
>>
> 
> Well, given 22nd is 10 days away, I guess this brings up the question,
> "what will it take to get us into release mode?". For me personally,
> I'd be willing to drop any other ppa work that I'm doing in favor of
> releasing.

Ok, up to you. As a side note, I will definitely give lesser priority on
PPA in next months after the release. Of course I'll still be around for
questions and important stuff though.

> Robert Treat
> conjecture: xzilla.net
> consulting: omniti.com

Re: [ppa-dev] Releasing 5.1

[Robert T. <ro...@xz...>]

On Fri, Apr 12, 2013 at 8:00 AM, Jehan-Guillaume (ioguix) de Rorthais
<io...@fr...> wrote:
> Hey,
>
>   23:36 < xzi11a> side note, i was looking at a patch from a while back,
> i might commit it by end of weekend if we arent in release mode yet.
>   23:37 < xzi11a> that said, i saw this:
> http://sourceforge.net/blog/upgrades-april22/
>   23:37 < xzi11a> we should probably try to release before april 22
>
> Agree, we should release before april 22th. As far as I know, we are not
> yet in "release mode", so any kind of fix or feature is still welcome.
>

Well, given 22nd is 10 days away, I guess this brings up the question,
"what will it take to get us into release mode?". For me personally,
I'd be willing to drop any other ppa work that I'm doing in favor of
releasing.


Robert Treat
conjecture: xzilla.net
consulting: omniti.com

Re: [ppa-dev] Releasing 5.1

[Karl O. P. <ko...@me...>]

On 04/12/2013 08:00:02 AM, Jehan-Guillaume (ioguix) de Rorthais wrote:

> Agree, we should release before april 22th. As far as I know, we are
> not
> yet in "release mode", so any kind of fix or feature is still 
> welcome.

I'd love to see this patch series go in.  There are 3 new features:

A) Allow import to replace existing table content.
B) Allow import into views.
C) Replace view content only when views support
deletion.

http://sourceforge.net/mailarchive/forum.php?thread_name=1351140199.27587.4%40mofo&forum_name=phppgadmin-devel

(6 patches total.)

I'd be happy to re-send the patches to the list.
(I've not gotten around to feeding them into github yet.)

Regards,

Karl <ko...@me...>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

[ppa-dev] Releasing 5.1

[Jehan-Guillaume (i. de R. <io...@fr...>]

Hey,

  23:36 < xzi11a> side note, i was looking at a patch from a while back,
i might commit it by end of weekend if we arent in release mode yet.
  23:37 < xzi11a> that said, i saw this:
http://sourceforge.net/blog/upgrades-april22/
  23:37 < xzi11a> we should probably try to release before april 22

Agree, we should release before april 22th. As far as I know, we are not
yet in "release mode", so any kind of fix or feature is still welcome.

Re: [ppa-dev] [ppa-commit] [phppgadmin/phppgadmin] c72407: Fix incorrect modification of bytea data when upda...

[Robert T. <ro...@xz...>]

Please be aware that these commits were part of a rebase to clean up
several recent commits into the tree. It's possible that this broke
your pull and you need to re-pull. That didn't seem to happen to any
of my copies, but I'd suggest you verify this sooner rather than
later. Thanks, and sorry for any trouble it causes.

Robert Treat


On Tue, Mar 26, 2013 at 1:21 PM, GitHub <no...@gi...> wrote:
>   Branch: refs/heads/master
>   Home:   https://github.com/phppgadmin/phppgadmin
>   Commit: c724073960af20805c60d873d94a0c38de958847
>       https://github.com/phppgadmin/phppgadmin/commit/c724073960af20805c60d873d94a0c38de958847
>   Author: Robert Treat <ro...@xz...>
>   Date:   2013-03-26 (Tue, 26 Mar 2013)
>
>   Changed paths:
>     M classes/Misc.php
>     M classes/database/Postgres.php
>     M classes/database/Postgres84.php
>     M libraries/adodb/drivers/adodb-postgres64.inc.php
>
>   Log Message:
>   -----------
>   Fix incorrect modification of bytea data when updating rows that contain bytea columns.
> Based on the POC patch from ioguix.
> This fixes SF Bug # 3243916.
>
>
>   Commit: acb88f625280a40cf50e2676758f2423a1a9ccc9
>       https://github.com/phppgadmin/phppgadmin/commit/acb88f625280a40cf50e2676758f2423a1a9ccc9
>   Author: Robert Treat <ro...@xz...>
>   Date:   2013-03-26 (Tue, 26 Mar 2013)
>
>   Changed paths:
>     M INSTALL
>
>   Log Message:
>   -----------
>   fix typo
>
>
>   Commit: 202be379e6e7cf7ad217d945d367fff448cb7256
>       https://github.com/phppgadmin/phppgadmin/commit/202be379e6e7cf7ad217d945d367fff448cb7256
>   Author: Robert Treat <ro...@xz...>
>   Date:   2013-03-26 (Tue, 26 Mar 2013)
>
>   Changed paths:
>     M INSTALL
>
>   Log Message:
>   -----------
>   reword information around statistics collector. based on bug report SF #3602305
>
>
>   Commit: 3f212d646ee7c94efbd2b6b7b7d18450d531e33d
>       https://github.com/phppgadmin/phppgadmin/commit/3f212d646ee7c94efbd2b6b7b7d18450d531e33d
>   Author: Jehan-Guillaume (ioguix) de Rorthais <io...@fr...>
>   Date:   2013-03-26 (Tue, 26 Mar 2013)
>
>   Changed paths:
>     M classes/Misc.php
>     M classes/PluginManager.php
>
>   Log Message:
>   -----------
>   Add plugin hook 'head'.
>
> Allows to add tags in <head /> from plugins
>
>
> Compare: https://github.com/phppgadmin/phppgadmin/compare/12af0f7cb55a...3f212d646ee7
>
> ------------------------------------------------------------------------------
> Own the Future-Intel&reg; Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest.
> Compete for recognition, cash, and the chance to get your game
> on Steam. $5K grand prize plus 10 genre and skill prizes.
> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> _______________________________________________
> phpPgAdmin-cvs mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phppgadmin-cvs
>

Re: [ppa-dev] [ppa-commit] [xzilla/phppgadmin] 9d5189: fix typo

[Jehan-Guillaume (i. de R. <io...@fr...>]

On 26/03/2013 18:42, Robert Treat wrote:
> On Tue, Mar 26, 2013 at 3:34 AM, Jehan-Guillaume (ioguix) de Rorthais
> <io...@fr...> wrote:
>> On 20/03/2013 21:03, Robert Treat wrote:
>>> Amazingly, while this is the commit I expected to see in the official
>>> repo, apparently it actually pulled in a bunch of additional stuff,
>>> which you can see in the official log. It's all just duplicate junk,
>>> so probably doesn't hurt anything, although I'd happily vote in favor
>>> of a rebase to remove it all and clean it up if others wanted to go
>>> that route. (rebasing pushed stuff is normally bad, but I am guessing
>>> no one would have done any branching off of whats public at this
>>> point). In any case... sorry about that :-(
>>
>> Well, as you said on IRC I pushed something, but if you are able to
>> clean the history, go ahead, I'll push my commit again easily later.
>>
>> I'm not sure to know how you can squash/ignore commits on Github. Does a
>> "git rebase -i" and a "git push" is allowed ??
>>
> 
> yes, although depending on what you do, a --force may be needed. The
> bigger issue is that anyone who has git pulled up to the current head
> will need to re-pull. Personally I don't think that's a big issue, but
> some people are sensitive. In any case, I'll see if I can clean it up.

Great.

>> Last thing, I might have a couple of minor things/cleanup to commit
>> because of two plugins: a private one for a customer and the E-maj one.
>> Philippe Beaudoin is waiting for some help from me since an eternity on
>> this.
>>
>> I would like to be able to release once this last plugin is working. To
>> make sure the plugin architecture answers its needs.
>>
> 
> Hmm, ok, in the mean time there are one or two patches I can look at.
> However, would it be reasonable to set a time limit on this work? With
> the bytea bug fixed, I think we have a viable release, and the fixes
> in trunk (9.2 support!) are more important for most people than
> anything else we are going to do in the immediate future, so I'd
> prefer to release in weeks rather than months.

Two weeks would be more than enough for me.

> Robert Treat
> 
>>>
>>>
>>> On Wed, Mar 20, 2013 at 12:56 PM, GitHub <no...@gi...> wrote:
>>>>   Branch: refs/heads/master
>>>>   Home:   https://github.com/xzilla/phppgadmin
>>>>   Commit: 9d518994c5b044c10ec175a5e2d9cec8e91c7ff5
>>>>       https://github.com/xzilla/phppgadmin/commit/9d518994c5b044c10ec175a5e2d9cec8e91c7ff5
>>>>   Author: Robert Treat <ro...@om...>
>>>>   Date:   2013-03-20 (Wed, 20 Mar 2013)
>>>>
>>>>   Changed paths:
>>>>     M INSTALL
>>>>
>>>>   Log Message:
>>>>   -----------
>>>>   fix typo
>>>>
>>>>
>>>>   Commit: 607eee54f103c48ecd5c904bb39abfa8fc3f42d3
>>>>       https://github.com/xzilla/phppgadmin/commit/607eee54f103c48ecd5c904bb39abfa8fc3f42d3
>>>>   Author: Robert Treat <ro...@om...>
>>>>   Date:   2013-03-20 (Wed, 20 Mar 2013)
>>>>
>>>>   Changed paths:
>>>>     M INSTALL
>>>>
>>>>   Log Message:
>>>>   -----------
>>>>   reword information around statistics collector. based on bug report SF #3602305
>>>>
>>>>
>>>> Compare: https://github.com/xzilla/phppgadmin/compare/5a6c372470a9...607eee54f103
>>>>

Re: [ppa-dev] [ppa-commit] [xzilla/phppgadmin] 9d5189: fix typo

[Robert T. <ro...@xz...>]

On Tue, Mar 26, 2013 at 3:34 AM, Jehan-Guillaume (ioguix) de Rorthais
<io...@fr...> wrote:
> On 20/03/2013 21:03, Robert Treat wrote:
>> Amazingly, while this is the commit I expected to see in the official
>> repo, apparently it actually pulled in a bunch of additional stuff,
>> which you can see in the official log. It's all just duplicate junk,
>> so probably doesn't hurt anything, although I'd happily vote in favor
>> of a rebase to remove it all and clean it up if others wanted to go
>> that route. (rebasing pushed stuff is normally bad, but I am guessing
>> no one would have done any branching off of whats public at this
>> point). In any case... sorry about that :-(
>
> Well, as you said on IRC I pushed something, but if you are able to
> clean the history, go ahead, I'll push my commit again easily later.
>
> I'm not sure to know how you can squash/ignore commits on Github. Does a
> "git rebase -i" and a "git push" is allowed ??
>

yes, although depending on what you do, a --force may be needed. The
bigger issue is that anyone who has git pulled up to the current head
will need to re-pull. Personally I don't think that's a big issue, but
some people are sensitive. In any case, I'll see if I can clean it up.

> Last thing, I might have a couple of minor things/cleanup to commit
> because of two plugins: a private one for a customer and the E-maj one.
> Philippe Beaudoin is waiting for some help from me since an eternity on
> this.
>
> I would like to be able to release once this last plugin is working. To
> make sure the plugin architecture answers its needs.
>

Hmm, ok, in the mean time there are one or two patches I can look at.
However, would it be reasonable to set a time limit on this work? With
the bytea bug fixed, I think we have a viable release, and the fixes
in trunk (9.2 support!) are more important for most people than
anything else we are going to do in the immediate future, so I'd
prefer to release in weeks rather than months.

Robert Treat

>>
>>
>> On Wed, Mar 20, 2013 at 12:56 PM, GitHub <no...@gi...> wrote:
>>>   Branch: refs/heads/master
>>>   Home:   https://github.com/xzilla/phppgadmin
>>>   Commit: 9d518994c5b044c10ec175a5e2d9cec8e91c7ff5
>>>       https://github.com/xzilla/phppgadmin/commit/9d518994c5b044c10ec175a5e2d9cec8e91c7ff5
>>>   Author: Robert Treat <ro...@om...>
>>>   Date:   2013-03-20 (Wed, 20 Mar 2013)
>>>
>>>   Changed paths:
>>>     M INSTALL
>>>
>>>   Log Message:
>>>   -----------
>>>   fix typo
>>>
>>>
>>>   Commit: 607eee54f103c48ecd5c904bb39abfa8fc3f42d3
>>>       https://github.com/xzilla/phppgadmin/commit/607eee54f103c48ecd5c904bb39abfa8fc3f42d3
>>>   Author: Robert Treat <ro...@om...>
>>>   Date:   2013-03-20 (Wed, 20 Mar 2013)
>>>
>>>   Changed paths:
>>>     M INSTALL
>>>
>>>   Log Message:
>>>   -----------
>>>   reword information around statistics collector. based on bug report SF #3602305
>>>
>>>
>>> Compare: https://github.com/xzilla/phppgadmin/compare/5a6c372470a9...607eee54f103
>>>

Re: [ppa-dev] [ppa-commit] [xzilla/phppgadmin] 9d5189: fix typo

[Jehan-Guillaume (i. de R. <io...@fr...>]

On 20/03/2013 21:03, Robert Treat wrote:
> Amazingly, while this is the commit I expected to see in the official
> repo, apparently it actually pulled in a bunch of additional stuff,
> which you can see in the official log. It's all just duplicate junk,
> so probably doesn't hurt anything, although I'd happily vote in favor
> of a rebase to remove it all and clean it up if others wanted to go
> that route. (rebasing pushed stuff is normally bad, but I am guessing
> no one would have done any branching off of whats public at this
> point). In any case... sorry about that :-(

Well, as you said on IRC I pushed something, but if you are able to
clean the history, go ahead, I'll push my commit again easily later.

I'm not sure to know how you can squash/ignore commits on Github. Does a
"git rebase -i" and a "git push" is allowed ??

Last thing, I might have a couple of minor things/cleanup to commit
because of two plugins: a private one for a customer and the E-maj one.
Philippe Beaudoin is waiting for some help from me since an eternity on
this.

I would like to be able to release once this last plugin is working. To
make sure the plugin architecture answers its needs.

Cheers,

> Robert Treat
> 
> 
> On Wed, Mar 20, 2013 at 12:56 PM, GitHub <no...@gi...> wrote:
>>   Branch: refs/heads/master
>>   Home:   https://github.com/xzilla/phppgadmin
>>   Commit: 9d518994c5b044c10ec175a5e2d9cec8e91c7ff5
>>       https://github.com/xzilla/phppgadmin/commit/9d518994c5b044c10ec175a5e2d9cec8e91c7ff5
>>   Author: Robert Treat <ro...@om...>
>>   Date:   2013-03-20 (Wed, 20 Mar 2013)
>>
>>   Changed paths:
>>     M INSTALL
>>
>>   Log Message:
>>   -----------
>>   fix typo
>>
>>
>>   Commit: 607eee54f103c48ecd5c904bb39abfa8fc3f42d3
>>       https://github.com/xzilla/phppgadmin/commit/607eee54f103c48ecd5c904bb39abfa8fc3f42d3
>>   Author: Robert Treat <ro...@om...>
>>   Date:   2013-03-20 (Wed, 20 Mar 2013)
>>
>>   Changed paths:
>>     M INSTALL
>>
>>   Log Message:
>>   -----------
>>   reword information around statistics collector. based on bug report SF #3602305
>>
>>
>> Compare: https://github.com/xzilla/phppgadmin/compare/5a6c372470a9...607eee54f103
>>

Re: [ppa-dev] [ppa-commit] [xzilla/phppgadmin] 9d5189: fix typo

[Robert T. <ro...@xz...>]

Amazingly, while this is the commit I expected to see in the official
repo, apparently it actually pulled in a bunch of additional stuff,
which you can see in the official log. It's all just duplicate junk,
so probably doesn't hurt anything, although I'd happily vote in favor
of a rebase to remove it all and clean it up if others wanted to go
that route. (rebasing pushed stuff is normally bad, but I am guessing
no one would have done any branching off of whats public at this
point). In any case... sorry about that :-(

Robert Treat


On Wed, Mar 20, 2013 at 12:56 PM, GitHub <no...@gi...> wrote:
>   Branch: refs/heads/master
>   Home:   https://github.com/xzilla/phppgadmin
>   Commit: 9d518994c5b044c10ec175a5e2d9cec8e91c7ff5
>       https://github.com/xzilla/phppgadmin/commit/9d518994c5b044c10ec175a5e2d9cec8e91c7ff5
>   Author: Robert Treat <ro...@om...>
>   Date:   2013-03-20 (Wed, 20 Mar 2013)
>
>   Changed paths:
>     M INSTALL
>
>   Log Message:
>   -----------
>   fix typo
>
>
>   Commit: 607eee54f103c48ecd5c904bb39abfa8fc3f42d3
>       https://github.com/xzilla/phppgadmin/commit/607eee54f103c48ecd5c904bb39abfa8fc3f42d3
>   Author: Robert Treat <ro...@om...>
>   Date:   2013-03-20 (Wed, 20 Mar 2013)
>
>   Changed paths:
>     M INSTALL
>
>   Log Message:
>   -----------
>   reword information around statistics collector. based on bug report SF #3602305
>
>
> Compare: https://github.com/xzilla/phppgadmin/compare/5a6c372470a9...607eee54f103
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> phpPgAdmin-cvs mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phppgadmin-cvs
>

Re: [ppa-dev] What to do about bytea bug...

[Jehan-Guillaume (i. de R. <io...@fr...>]

On 18/03/2013 16:35, Robert Treat wrote:
> Thanks Ian and Marek, that sounds like what we needed. I'm going to go
> ahead and work on merging it into the main PPA repo.

Yeah, I already did quick test with my version of the patch. There was
no regression with <9.0 (tested on 8.4).

Thanks for your patch, the way you handle "bytea_output" is obviously in
a better shape :)

Please, push on official repo.

> 
> Robert Treat
> 
> On Mon, Mar 18, 2013 at 9:11 AM, Marek Černocký <ma...@ma...> wrote:
>> Robert Treat píše v Pá 15. 03. 2013 v 00:27 -0500:
>>> On Fri, Mar 8, 2013 at 3:54 AM, Jehan-Guillaume (ioguix) de Rorthais
>>> <io...@fr...> wrote:
>>>> On 08/03/2013 03:37, Robert Treat wrote:
>>>>> On Thu, Mar 7, 2013 at 2:43 PM, Jehan-Guillaume (ioguix) de Rorthais
>>>>> <io...@fr...> wrote:
>>>>>>>> While trying to find if it is possible to print bytea in "escape" format
>>>>>>>> under 9.0+ correctly, I found that our version of adodb is messing with
>>>>>>>> bytea as well. Yeah! Some more fun :)
>>>>>>>>
>>>>>>>> In libraries/adodb/drivers/adodb-postgres64.inc.php, see L913-915 and
>>>>>>>> 950-969.
>>>>>>>>
>>>>>>>> There was a fix in recent versions about that, but it only use
>>>>>>>> pg_unescape_bytea instead of a weird "eval()" block. So I guess it just
>>>>>>>> returns the raw binary field. That would explain why we use
>>>>>>>> pg_escape_bytea on such fields in "classes/database/Postgres.php:233".
>>>>>>>> That was not making sense at all for me until now...
>>>>>
>>>>> Does the more recent adodb have any postgres 9.x specific code (rather
>>>>> than executing what is in adodb-postgres64.inc.php). ISTM they would
>>>>> have had to add or change code to deal with the 9.x switch to hex
>>>>> instead of escape.
>>>>
>>>> I already downloaded and checked what they did in postres9 of their last
>>>> release. Nothing about bytea and I'm not suprised: ADOdb automatically
>>>> unescape bytea to give it as a raw binary using pg_unescape_bytea. So
>>>> they don't mess with encode/hex format as they return the third
>>>> candidate: raw data.
>>>>
>>>>>>>> PFA a quick'n'dirty patch that seems to fix the issue (with my very
>>>>>>>> quick and trivial tests) by forbidding ADOdb to unescape bytea. It
>>>>>>>> probably needs some more test and just force the escape format with 9.0+.
>>>>>>>>
>>>>>>>> AFAICS, ADOdb doe not allow to switch this behaviour off.
>>>>>>>>
>>>>>>>> BTW, I guess we should upgrade our ADOdb library. Thoughts about that?
>>>>>>>>
>>>>>>>
>>>>>>> I sort of feel that we have a private fork of ADOdb at this point, so
>>>>>>> I'd be pretty scared to update it.
>>>>>>
>>>>>> Mh, I don't remember having patched ADOdb since last update.
>>>>>>
>>>>>>> Unless you think it will help solve
>>>>>>> the bytea problem immediately in front of us, I'd at least say we put
>>>>>>> it off till after a release.
>>>>>>
>>>>>> Ok. I really think we should drop it though.
>>>>>>
>>>>>
>>>>> Well, yes. It doesn't really buy us anything anymore. Although, what
>>>>> we really need is an abstraction layer that would allow us to work
>>>>> with both pg_* and pdo. Grand plans indeed.
>>>>
>>>> Not sure to understand why we need to support both, but it doesn't looks
>>>> so hard.
>>>>
>>>>> <snip>
>>>>>>> That said, before we worry about that, I'd like to see it work in any
>>>>>>> way/shape/form, so I'll be looking at your patch in just a bit to see.
>>>>>>> If we can get it working *at all* then I think we can worry about
>>>>>>> making it more flexible.
>>>>>>
>>>>>> Great. I'm waiting for your feedback and feeling then.
>>>>>>
>>>>>
>>>>> Well, initial testing of the patch looks like it works. I think the
>>>>> part I was missing was the change by adodb, which I suspect would have
>>>>> broken things all kinds of different subtle ways depending on what
>>>>> else you were trying.
>>>>
>>>> Exact. But most of everything else, it explains why we were doing a
>>>> "pg_escape_bytea" to RE-escape binary data !! This is a non-sense.
>>>>
>>>>> So, I have renwed hope, but I need to think about this. Let me play
>>>>> with the code some more and see what I can do. Thanks! Really, thanks!
>>>>
>>>> ok, I'm looking forward to see what you can do with that :)
>>>>
>>>
>>> So, after digging into a few different pieces of this, and some
>>> additional discussion with ioguix, we've decided to shoot for a simple
>>> patch that prevents the data from getting modified incorrectly. The
>>> following is in my tree as the proposed fix, which is very similar to
>>> ioguix original patch.
>>>
>>> https://github.com/xzilla/phppgadmin/commit/1ab13f459a8ac95c8970d1100edca750ca2048ee
>>>
>>> I have not tested it on 8.4, as I don't currently have an 8.4 set up.
>>> If anyone can test it and verify, that would be swell, otherwise I'll
>>> see about getting an 8.4 running in a few days, as I think we should
>>> test that before we commit this to mainline. Barring any issues
>>> though, we can commit this and move on toward a new release, and then
>>> revisit the larger bytea handling.
>>>
>>> Robert Treat
>>> http://surge.omniti.com
>>> The CFP is open, please submit!
>>>
>>
>> I tested it with 8.3 and it seems fixed well for this version.
>>
>> Thanks for your work
>> Marek Černocký
>>
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_d2d_mar
>>> _______________________________________________
>>> phpPgAdmin-devel mailing list
>>> php...@li...
>>> https://lists.sourceforge.net/lists/listinfo/phppgadmin-devel
>>
>>

Re: [ppa-dev] What to do about bytea bug...

[Robert T. <ro...@xz...>]

Thanks Ian and Marek, that sounds like what we needed. I'm going to go
ahead and work on merging it into the main PPA repo.

Robert Treat

On Mon, Mar 18, 2013 at 9:11 AM, Marek Černocký <ma...@ma...> wrote:
> Robert Treat píše v Pá 15. 03. 2013 v 00:27 -0500:
>> On Fri, Mar 8, 2013 at 3:54 AM, Jehan-Guillaume (ioguix) de Rorthais
>> <io...@fr...> wrote:
>> > On 08/03/2013 03:37, Robert Treat wrote:
>> >> On Thu, Mar 7, 2013 at 2:43 PM, Jehan-Guillaume (ioguix) de Rorthais
>> >> <io...@fr...> wrote:
>> >>>>> While trying to find if it is possible to print bytea in "escape" format
>> >>>>> under 9.0+ correctly, I found that our version of adodb is messing with
>> >>>>> bytea as well. Yeah! Some more fun :)
>> >>>>>
>> >>>>> In libraries/adodb/drivers/adodb-postgres64.inc.php, see L913-915 and
>> >>>>> 950-969.
>> >>>>>
>> >>>>> There was a fix in recent versions about that, but it only use
>> >>>>> pg_unescape_bytea instead of a weird "eval()" block. So I guess it just
>> >>>>> returns the raw binary field. That would explain why we use
>> >>>>> pg_escape_bytea on such fields in "classes/database/Postgres.php:233".
>> >>>>> That was not making sense at all for me until now...
>> >>
>> >> Does the more recent adodb have any postgres 9.x specific code (rather
>> >> than executing what is in adodb-postgres64.inc.php). ISTM they would
>> >> have had to add or change code to deal with the 9.x switch to hex
>> >> instead of escape.
>> >
>> > I already downloaded and checked what they did in postres9 of their last
>> > release. Nothing about bytea and I'm not suprised: ADOdb automatically
>> > unescape bytea to give it as a raw binary using pg_unescape_bytea. So
>> > they don't mess with encode/hex format as they return the third
>> > candidate: raw data.
>> >
>> >>>>> PFA a quick'n'dirty patch that seems to fix the issue (with my very
>> >>>>> quick and trivial tests) by forbidding ADOdb to unescape bytea. It
>> >>>>> probably needs some more test and just force the escape format with 9.0+.
>> >>>>>
>> >>>>> AFAICS, ADOdb doe not allow to switch this behaviour off.
>> >>>>>
>> >>>>> BTW, I guess we should upgrade our ADOdb library. Thoughts about that?
>> >>>>>
>> >>>>
>> >>>> I sort of feel that we have a private fork of ADOdb at this point, so
>> >>>> I'd be pretty scared to update it.
>> >>>
>> >>> Mh, I don't remember having patched ADOdb since last update.
>> >>>
>> >>>> Unless you think it will help solve
>> >>>> the bytea problem immediately in front of us, I'd at least say we put
>> >>>> it off till after a release.
>> >>>
>> >>> Ok. I really think we should drop it though.
>> >>>
>> >>
>> >> Well, yes. It doesn't really buy us anything anymore. Although, what
>> >> we really need is an abstraction layer that would allow us to work
>> >> with both pg_* and pdo. Grand plans indeed.
>> >
>> > Not sure to understand why we need to support both, but it doesn't looks
>> > so hard.
>> >
>> >> <snip>
>> >>>> That said, before we worry about that, I'd like to see it work in any
>> >>>> way/shape/form, so I'll be looking at your patch in just a bit to see.
>> >>>> If we can get it working *at all* then I think we can worry about
>> >>>> making it more flexible.
>> >>>
>> >>> Great. I'm waiting for your feedback and feeling then.
>> >>>
>> >>
>> >> Well, initial testing of the patch looks like it works. I think the
>> >> part I was missing was the change by adodb, which I suspect would have
>> >> broken things all kinds of different subtle ways depending on what
>> >> else you were trying.
>> >
>> > Exact. But most of everything else, it explains why we were doing a
>> > "pg_escape_bytea" to RE-escape binary data !! This is a non-sense.
>> >
>> >> So, I have renwed hope, but I need to think about this. Let me play
>> >> with the code some more and see what I can do. Thanks! Really, thanks!
>> >
>> > ok, I'm looking forward to see what you can do with that :)
>> >
>>
>> So, after digging into a few different pieces of this, and some
>> additional discussion with ioguix, we've decided to shoot for a simple
>> patch that prevents the data from getting modified incorrectly. The
>> following is in my tree as the proposed fix, which is very similar to
>> ioguix original patch.
>>
>> https://github.com/xzilla/phppgadmin/commit/1ab13f459a8ac95c8970d1100edca750ca2048ee
>>
>> I have not tested it on 8.4, as I don't currently have an 8.4 set up.
>> If anyone can test it and verify, that would be swell, otherwise I'll
>> see about getting an 8.4 running in a few days, as I think we should
>> test that before we commit this to mainline. Barring any issues
>> though, we can commit this and move on toward a new release, and then
>> revisit the larger bytea handling.
>>
>> Robert Treat
>> http://surge.omniti.com
>> The CFP is open, please submit!
>>
>
> I tested it with 8.3 and it seems fixed well for this version.
>
> Thanks for your work
> Marek Černocký
>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_mar
>> _______________________________________________
>> phpPgAdmin-devel mailing list
>> php...@li...
>> https://lists.sourceforge.net/lists/listinfo/phppgadmin-devel
>
>

Re: [ppa-dev] What to do about bytea bug...

[Marek Č. <ma...@ma...>]

Robert Treat píše v Pá 15. 03. 2013 v 00:27 -0500:
> On Fri, Mar 8, 2013 at 3:54 AM, Jehan-Guillaume (ioguix) de Rorthais
> <io...@fr...> wrote:
> > On 08/03/2013 03:37, Robert Treat wrote:
> >> On Thu, Mar 7, 2013 at 2:43 PM, Jehan-Guillaume (ioguix) de Rorthais
> >> <io...@fr...> wrote:
> >>>>> While trying to find if it is possible to print bytea in "escape" format
> >>>>> under 9.0+ correctly, I found that our version of adodb is messing with
> >>>>> bytea as well. Yeah! Some more fun :)
> >>>>>
> >>>>> In libraries/adodb/drivers/adodb-postgres64.inc.php, see L913-915 and
> >>>>> 950-969.
> >>>>>
> >>>>> There was a fix in recent versions about that, but it only use
> >>>>> pg_unescape_bytea instead of a weird "eval()" block. So I guess it just
> >>>>> returns the raw binary field. That would explain why we use
> >>>>> pg_escape_bytea on such fields in "classes/database/Postgres.php:233".
> >>>>> That was not making sense at all for me until now...
> >>
> >> Does the more recent adodb have any postgres 9.x specific code (rather
> >> than executing what is in adodb-postgres64.inc.php). ISTM they would
> >> have had to add or change code to deal with the 9.x switch to hex
> >> instead of escape.
> >
> > I already downloaded and checked what they did in postres9 of their last
> > release. Nothing about bytea and I'm not suprised: ADOdb automatically
> > unescape bytea to give it as a raw binary using pg_unescape_bytea. So
> > they don't mess with encode/hex format as they return the third
> > candidate: raw data.
> >
> >>>>> PFA a quick'n'dirty patch that seems to fix the issue (with my very
> >>>>> quick and trivial tests) by forbidding ADOdb to unescape bytea. It
> >>>>> probably needs some more test and just force the escape format with 9.0+.
> >>>>>
> >>>>> AFAICS, ADOdb doe not allow to switch this behaviour off.
> >>>>>
> >>>>> BTW, I guess we should upgrade our ADOdb library. Thoughts about that?
> >>>>>
> >>>>
> >>>> I sort of feel that we have a private fork of ADOdb at this point, so
> >>>> I'd be pretty scared to update it.
> >>>
> >>> Mh, I don't remember having patched ADOdb since last update.
> >>>
> >>>> Unless you think it will help solve
> >>>> the bytea problem immediately in front of us, I'd at least say we put
> >>>> it off till after a release.
> >>>
> >>> Ok. I really think we should drop it though.
> >>>
> >>
> >> Well, yes. It doesn't really buy us anything anymore. Although, what
> >> we really need is an abstraction layer that would allow us to work
> >> with both pg_* and pdo. Grand plans indeed.
> >
> > Not sure to understand why we need to support both, but it doesn't looks
> > so hard.
> >
> >> <snip>
> >>>> That said, before we worry about that, I'd like to see it work in any
> >>>> way/shape/form, so I'll be looking at your patch in just a bit to see.
> >>>> If we can get it working *at all* then I think we can worry about
> >>>> making it more flexible.
> >>>
> >>> Great. I'm waiting for your feedback and feeling then.
> >>>
> >>
> >> Well, initial testing of the patch looks like it works. I think the
> >> part I was missing was the change by adodb, which I suspect would have
> >> broken things all kinds of different subtle ways depending on what
> >> else you were trying.
> >
> > Exact. But most of everything else, it explains why we were doing a
> > "pg_escape_bytea" to RE-escape binary data !! This is a non-sense.
> >
> >> So, I have renwed hope, but I need to think about this. Let me play
> >> with the code some more and see what I can do. Thanks! Really, thanks!
> >
> > ok, I'm looking forward to see what you can do with that :)
> >
> 
> So, after digging into a few different pieces of this, and some
> additional discussion with ioguix, we've decided to shoot for a simple
> patch that prevents the data from getting modified incorrectly. The
> following is in my tree as the proposed fix, which is very similar to
> ioguix original patch.
> 
> https://github.com/xzilla/phppgadmin/commit/1ab13f459a8ac95c8970d1100edca750ca2048ee
> 
> I have not tested it on 8.4, as I don't currently have an 8.4 set up.
> If anyone can test it and verify, that would be swell, otherwise I'll
> see about getting an 8.4 running in a few days, as I think we should
> test that before we commit this to mainline. Barring any issues
> though, we can commit this and move on toward a new release, and then
> revisit the larger bytea handling.
> 
> Robert Treat
> http://surge.omniti.com
> The CFP is open, please submit!
> 

I tested it with 8.3 and it seems fixed well for this version.

Thanks for your work
Marek Černocký

> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> phpPgAdmin-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phppgadmin-devel

Re: [ppa-dev] What to do about bytea bug...

[Ian L. B. <ba...@gm...>]

2013/3/15 Robert Treat <ro...@xz...>:
> On Fri, Mar 8, 2013 at 3:54 AM, Jehan-Guillaume (ioguix) de Rorthais
> <io...@fr...> wrote:
>> On 08/03/2013 03:37, Robert Treat wrote:
>>> On Thu, Mar 7, 2013 at 2:43 PM, Jehan-Guillaume (ioguix) de Rorthais
>>> <io...@fr...> wrote:
>>>>>> While trying to find if it is possible to print bytea in "escape" format
>>>>>> under 9.0+ correctly, I found that our version of adodb is messing with
>>>>>> bytea as well. Yeah! Some more fun :)
>>>>>>
>>>>>> In libraries/adodb/drivers/adodb-postgres64.inc.php, see L913-915 and
>>>>>> 950-969.
>>>>>>
>>>>>> There was a fix in recent versions about that, but it only use
>>>>>> pg_unescape_bytea instead of a weird "eval()" block. So I guess it just
>>>>>> returns the raw binary field. That would explain why we use
>>>>>> pg_escape_bytea on such fields in "classes/database/Postgres.php:233".
>>>>>> That was not making sense at all for me until now...
>>>
>>> Does the more recent adodb have any postgres 9.x specific code (rather
>>> than executing what is in adodb-postgres64.inc.php). ISTM they would
>>> have had to add or change code to deal with the 9.x switch to hex
>>> instead of escape.
>>
>> I already downloaded and checked what they did in postres9 of their last
>> release. Nothing about bytea and I'm not suprised: ADOdb automatically
>> unescape bytea to give it as a raw binary using pg_unescape_bytea. So
>> they don't mess with encode/hex format as they return the third
>> candidate: raw data.
>>
>>>>>> PFA a quick'n'dirty patch that seems to fix the issue (with my very
>>>>>> quick and trivial tests) by forbidding ADOdb to unescape bytea. It
>>>>>> probably needs some more test and just force the escape format with 9.0+.
>>>>>>
>>>>>> AFAICS, ADOdb doe not allow to switch this behaviour off.
>>>>>>
>>>>>> BTW, I guess we should upgrade our ADOdb library. Thoughts about that?
>>>>>>
>>>>>
>>>>> I sort of feel that we have a private fork of ADOdb at this point, so
>>>>> I'd be pretty scared to update it.
>>>>
>>>> Mh, I don't remember having patched ADOdb since last update.
>>>>
>>>>> Unless you think it will help solve
>>>>> the bytea problem immediately in front of us, I'd at least say we put
>>>>> it off till after a release.
>>>>
>>>> Ok. I really think we should drop it though.
>>>>
>>>
>>> Well, yes. It doesn't really buy us anything anymore. Although, what
>>> we really need is an abstraction layer that would allow us to work
>>> with both pg_* and pdo. Grand plans indeed.
>>
>> Not sure to understand why we need to support both, but it doesn't looks
>> so hard.
>>
>>> <snip>
>>>>> That said, before we worry about that, I'd like to see it work in any
>>>>> way/shape/form, so I'll be looking at your patch in just a bit to see.
>>>>> If we can get it working *at all* then I think we can worry about
>>>>> making it more flexible.
>>>>
>>>> Great. I'm waiting for your feedback and feeling then.
>>>>
>>>
>>> Well, initial testing of the patch looks like it works. I think the
>>> part I was missing was the change by adodb, which I suspect would have
>>> broken things all kinds of different subtle ways depending on what
>>> else you were trying.
>>
>> Exact. But most of everything else, it explains why we were doing a
>> "pg_escape_bytea" to RE-escape binary data !! This is a non-sense.
>>
>>> So, I have renwed hope, but I need to think about this. Let me play
>>> with the code some more and see what I can do. Thanks! Really, thanks!
>>
>> ok, I'm looking forward to see what you can do with that :)
>>
>
> So, after digging into a few different pieces of this, and some
> additional discussion with ioguix, we've decided to shoot for a simple
> patch that prevents the data from getting modified incorrectly. The
> following is in my tree as the proposed fix, which is very similar to
> ioguix original patch.
>
> https://github.com/xzilla/phppgadmin/commit/1ab13f459a8ac95c8970d1100edca750ca2048ee
>
> I have not tested it on 8.4, as I don't currently have an 8.4 set up.
> If anyone can test it and verify, that would be swell, otherwise I'll
> see about getting an 8.4 running in a few days, as I think we should
> test that before we commit this to mainline. Barring any issues
> though, we can commit this and move on toward a new release, and then
> revisit the larger bytea handling.

I've just tested this with 8.4 (as I happen to have an instance running)
using the ppa repository HEAD and merging your tree.
It *seems* to work, i.e. editing a row with a bytea column and saving the
row leaves the bytea column unchanged. Unfortunately I've kind of
lost track of the discussion, if that's not what needs testing please let
me know :)

Regards

Ian Barwick

Re: [ppa-dev] What to do about bytea bug...

[Robert T. <ro...@xz...>]

On Fri, Mar 8, 2013 at 3:54 AM, Jehan-Guillaume (ioguix) de Rorthais
<io...@fr...> wrote:
> On 08/03/2013 03:37, Robert Treat wrote:
>> On Thu, Mar 7, 2013 at 2:43 PM, Jehan-Guillaume (ioguix) de Rorthais
>> <io...@fr...> wrote:
>>>>> While trying to find if it is possible to print bytea in "escape" format
>>>>> under 9.0+ correctly, I found that our version of adodb is messing with
>>>>> bytea as well. Yeah! Some more fun :)
>>>>>
>>>>> In libraries/adodb/drivers/adodb-postgres64.inc.php, see L913-915 and
>>>>> 950-969.
>>>>>
>>>>> There was a fix in recent versions about that, but it only use
>>>>> pg_unescape_bytea instead of a weird "eval()" block. So I guess it just
>>>>> returns the raw binary field. That would explain why we use
>>>>> pg_escape_bytea on such fields in "classes/database/Postgres.php:233".
>>>>> That was not making sense at all for me until now...
>>
>> Does the more recent adodb have any postgres 9.x specific code (rather
>> than executing what is in adodb-postgres64.inc.php). ISTM they would
>> have had to add or change code to deal with the 9.x switch to hex
>> instead of escape.
>
> I already downloaded and checked what they did in postres9 of their last
> release. Nothing about bytea and I'm not suprised: ADOdb automatically
> unescape bytea to give it as a raw binary using pg_unescape_bytea. So
> they don't mess with encode/hex format as they return the third
> candidate: raw data.
>
>>>>> PFA a quick'n'dirty patch that seems to fix the issue (with my very
>>>>> quick and trivial tests) by forbidding ADOdb to unescape bytea. It
>>>>> probably needs some more test and just force the escape format with 9.0+.
>>>>>
>>>>> AFAICS, ADOdb doe not allow to switch this behaviour off.
>>>>>
>>>>> BTW, I guess we should upgrade our ADOdb library. Thoughts about that?
>>>>>
>>>>
>>>> I sort of feel that we have a private fork of ADOdb at this point, so
>>>> I'd be pretty scared to update it.
>>>
>>> Mh, I don't remember having patched ADOdb since last update.
>>>
>>>> Unless you think it will help solve
>>>> the bytea problem immediately in front of us, I'd at least say we put
>>>> it off till after a release.
>>>
>>> Ok. I really think we should drop it though.
>>>
>>
>> Well, yes. It doesn't really buy us anything anymore. Although, what
>> we really need is an abstraction layer that would allow us to work
>> with both pg_* and pdo. Grand plans indeed.
>
> Not sure to understand why we need to support both, but it doesn't looks
> so hard.
>
>> <snip>
>>>> That said, before we worry about that, I'd like to see it work in any
>>>> way/shape/form, so I'll be looking at your patch in just a bit to see.
>>>> If we can get it working *at all* then I think we can worry about
>>>> making it more flexible.
>>>
>>> Great. I'm waiting for your feedback and feeling then.
>>>
>>
>> Well, initial testing of the patch looks like it works. I think the
>> part I was missing was the change by adodb, which I suspect would have
>> broken things all kinds of different subtle ways depending on what
>> else you were trying.
>
> Exact. But most of everything else, it explains why we were doing a
> "pg_escape_bytea" to RE-escape binary data !! This is a non-sense.
>
>> So, I have renwed hope, but I need to think about this. Let me play
>> with the code some more and see what I can do. Thanks! Really, thanks!
>
> ok, I'm looking forward to see what you can do with that :)
>

So, after digging into a few different pieces of this, and some
additional discussion with ioguix, we've decided to shoot for a simple
patch that prevents the data from getting modified incorrectly. The
following is in my tree as the proposed fix, which is very similar to
ioguix original patch.

https://github.com/xzilla/phppgadmin/commit/1ab13f459a8ac95c8970d1100edca750ca2048ee

I have not tested it on 8.4, as I don't currently have an 8.4 set up.
If anyone can test it and verify, that would be swell, otherwise I'll
see about getting an 8.4 running in a few days, as I think we should
test that before we commit this to mainline. Barring any issues
though, we can commit this and move on toward a new release, and then
revisit the larger bytea handling.

Robert Treat
http://surge.omniti.com
The CFP is open, please submit!

Re: [ppa-dev] What to do about bytea bug...

[Karl O. P. <ko...@me...>]

On 03/08/2013 02:54:16 AM, Jehan-Guillaume (ioguix) de Rorthais wrote:
> On 08/03/2013 03:37, Robert Treat wrote:

> > Well, yes. It doesn't really buy us anything anymore. Although, 
> what
> > we really need is an abstraction layer that would allow us to work
> > with both pg_* and pdo. Grand plans indeed.
> 
> Not sure to understand why we need to support both, but it doesn't
> looks
> so hard.

I don't understand either.  Why not use either/both?  It's not
like they won't be there.

I have a better grand plan.  Let's redo the whole thing
in python!  My vote is for pyramid.  :-)



Karl <ko...@me...>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

Re: [ppa-dev] What to do about bytea bug...

[Jehan-Guillaume (i. de R. <io...@fr...>]

On 08/03/2013 03:37, Robert Treat wrote:
> On Thu, Mar 7, 2013 at 2:43 PM, Jehan-Guillaume (ioguix) de Rorthais
> <io...@fr...> wrote:
>>>> While trying to find if it is possible to print bytea in "escape" format
>>>> under 9.0+ correctly, I found that our version of adodb is messing with
>>>> bytea as well. Yeah! Some more fun :)
>>>>
>>>> In libraries/adodb/drivers/adodb-postgres64.inc.php, see L913-915 and
>>>> 950-969.
>>>>
>>>> There was a fix in recent versions about that, but it only use
>>>> pg_unescape_bytea instead of a weird "eval()" block. So I guess it just
>>>> returns the raw binary field. That would explain why we use
>>>> pg_escape_bytea on such fields in "classes/database/Postgres.php:233".
>>>> That was not making sense at all for me until now...
> 
> Does the more recent adodb have any postgres 9.x specific code (rather
> than executing what is in adodb-postgres64.inc.php). ISTM they would
> have had to add or change code to deal with the 9.x switch to hex
> instead of escape.

I already downloaded and checked what they did in postres9 of their last
release. Nothing about bytea and I'm not suprised: ADOdb automatically
unescape bytea to give it as a raw binary using pg_unescape_bytea. So
they don't mess with encode/hex format as they return the third
candidate: raw data.

>>>> PFA a quick'n'dirty patch that seems to fix the issue (with my very
>>>> quick and trivial tests) by forbidding ADOdb to unescape bytea. It
>>>> probably needs some more test and just force the escape format with 9.0+.
>>>>
>>>> AFAICS, ADOdb doe not allow to switch this behaviour off.
>>>>
>>>> BTW, I guess we should upgrade our ADOdb library. Thoughts about that?
>>>>
>>>
>>> I sort of feel that we have a private fork of ADOdb at this point, so
>>> I'd be pretty scared to update it.
>>
>> Mh, I don't remember having patched ADOdb since last update.
>>
>>> Unless you think it will help solve
>>> the bytea problem immediately in front of us, I'd at least say we put
>>> it off till after a release.
>>
>> Ok. I really think we should drop it though.
>>
> 
> Well, yes. It doesn't really buy us anything anymore. Although, what
> we really need is an abstraction layer that would allow us to work
> with both pg_* and pdo. Grand plans indeed.

Not sure to understand why we need to support both, but it doesn't looks
so hard.

> <snip>
>>> That said, before we worry about that, I'd like to see it work in any
>>> way/shape/form, so I'll be looking at your patch in just a bit to see.
>>> If we can get it working *at all* then I think we can worry about
>>> making it more flexible.
>>
>> Great. I'm waiting for your feedback and feeling then.
>>
> 
> Well, initial testing of the patch looks like it works. I think the
> part I was missing was the change by adodb, which I suspect would have
> broken things all kinds of different subtle ways depending on what
> else you were trying.

Exact. But most of everything else, it explains why we were doing a
"pg_escape_bytea" to RE-escape binary data !! This is a non-sense.

> So, I have renwed hope, but I need to think about this. Let me play
> with the code some more and see what I can do. Thanks! Really, thanks!

ok, I'm looking forward to see what you can do with that :)

> Robert Treat
> http://surge.omniti.com
> The CFP is open, please submit!

Re: [ppa-dev] What to do about bytea bug...

[Robert T. <ro...@xz...>]

On Thu, Mar 7, 2013 at 2:43 PM, Jehan-Guillaume (ioguix) de Rorthais
<io...@fr...> wrote:
>>> While trying to find if it is possible to print bytea in "escape" format
>>> under 9.0+ correctly, I found that our version of adodb is messing with
>>> bytea as well. Yeah! Some more fun :)
>>>
>>> In libraries/adodb/drivers/adodb-postgres64.inc.php, see L913-915 and
>>> 950-969.
>>>
>>> There was a fix in recent versions about that, but it only use
>>> pg_unescape_bytea instead of a weird "eval()" block. So I guess it just
>>> returns the raw binary field. That would explain why we use
>>> pg_escape_bytea on such fields in "classes/database/Postgres.php:233".
>>> That was not making sense at all for me until now...

Does the more recent adodb have any postgres 9.x specific code (rather
than executing what is in adodb-postgres64.inc.php). ISTM they would
have had to add or change code to deal with the 9.x switch to hex
instead of escape.

>>>
>>> PFA a quick'n'dirty patch that seems to fix the issue (with my very
>>> quick and trivial tests) by forbidding ADOdb to unescape bytea. It
>>> probably needs some more test and just force the escape format with 9.0+.
>>>
>>> AFAICS, ADOdb doe not allow to switch this behaviour off.
>>>
>>> BTW, I guess we should upgrade our ADOdb library. Thoughts about that?
>>>
>>
>> I sort of feel that we have a private fork of ADOdb at this point, so
>> I'd be pretty scared to update it.
>
> Mh, I don't remember having patched ADOdb since last update.
>
>> Unless you think it will help solve
>> the bytea problem immediately in front of us, I'd at least say we put
>> it off till after a release.
>
> Ok. I really think we should drop it though.
>

Well, yes. It doesn't really buy us anything anymore. Although, what
we really need is an abstraction layer that would allow us to work
with both pg_* and pdo. Grand plans indeed.

<snip>
>> That said, before we worry about that, I'd like to see it work in any
>> way/shape/form, so I'll be looking at your patch in just a bit to see.
>> If we can get it working *at all* then I think we can worry about
>> making it more flexible.
>
> Great. I'm waiting for your feedback and feeling then.
>

Well, initial testing of the patch looks like it works. I think the
part I was missing was the change by adodb, which I suspect would have
broken things all kinds of different subtle ways depending on what
else you were trying.

So, I have renwed hope, but I need to think about this. Let me play
with the code some more and see what I can do. Thanks! Really, thanks!


Robert Treat
http://surge.omniti.com
The CFP is open, please submit!

Re: [ppa-dev] What to do about bytea bug...

[Karl O. P. <ko...@me...>]

On 03/07/2013 01:43:46 PM, Jehan-Guillaume (ioguix) de Rorthais wrote:
> On 07/03/2013 20:07, Robert Treat wrote:
> > On Thu, Mar 7, 2013 at 12:15 PM, Jehan-Guillaume (ioguix) de
> Rorthais
> > <io...@fr...> wrote:
> >> On 19/02/2013 11:38, Jehan-Guillaume (ioguix) de Rorthais wrote:
> >>> On 19/02/2013 02:57, Karl O. Pinc wrote:
> >>>> On 02/18/2013 06:27:46 PM, Jehan-Guillaume (ioguix) de Rorthais

> > WRT solving the bytea problem, I had a thought that the right 
> answer
> > might be to use the "format" column to allow users to switch 
> between
> > hex and escape.
> 
> Yeah, I was considering this as well. The only problem about that is
> that this is more than a fix, it's a full new feature. Not sure how
> longer it would be to dev.
> If we are taking this way (which is probably the best for everyone,
> but
> longer to dev), it requires to add a navlink to switch between format
> on
> simple browsing page as well.
> 
> > I think we can detect (or force) this information from
> > the server to set it initially.
> 
> I don't understand what you mean. Based on the server version, we can
> set the default format to use for printing values, yes. But we can 
> not
> know what was the format used by the user when the data was inserted.
> 

I'm in favor of doing the formatting on the client.  Having the
server deliver data in one way only, and sending a flag to the
client to tell how to display it.  The client could even
toggle the flag and dynamically change the result.  The
flag default would be set in the config on the server.

Having the external bytea representation change dynamically
might not be something to do right away, but if you start
by having the client side do the work then you can easily
go there.  You've got options for having the formatting be
persistent/tied to the login cookie, etc. etc.



Karl <ko...@me...>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

Re: [ppa-dev] What to do about bytea bug...

[Robert T. <ro...@xz...>]

On Thu, Mar 7, 2013 at 12:15 PM, Jehan-Guillaume (ioguix) de Rorthais
<io...@fr...> wrote:
> On 19/02/2013 11:38, Jehan-Guillaume (ioguix) de Rorthais wrote:
>> On 19/02/2013 02:57, Karl O. Pinc wrote:
>>> On 02/18/2013 06:27:46 PM, Jehan-Guillaume (ioguix) de Rorthais wrote:
>>>
>>>> We can not know what was the original input format. So in my opinion,
>>>> we
>>>> should add a parameter to handle bytea_output in config.inc.php and
>>>> make
>>>> this a user decision. Presently, we just force it to 'hex' and
>>>> corrupt
>>>> it on the way. The other option is to pick 'hex' (thus, keep using
>>>> pg_escape_bytea), but fix the way we print it.
>>>
>>> Hex is the canonical pg representation so IMHO we will at least
>>> want the option to display/edit in hex.  Since we're doing
>>> hex anyway then for the moment just do everything in hex.
>>
>> Yeah, we are doing 'hex' with 9.0+, but without really noticing it
>> before now.
>>
>> 'hex' is the fastest format anyway. And only supporting 'hex' correctly
>> for 9.0+ is probably the easiest and quickest patch.
>>
>> I might not have time to work on this before one or two weeks, but I'll
>> try...unless someone else could jump on this issue as we have a strategy
>> now. I'll be able to review any patch for sure.
>
> Back on this subject.
>
> While trying to find if it is possible to print bytea in "escape" format
> under 9.0+ correctly, I found that our version of adodb is messing with
> bytea as well. Yeah! Some more fun :)
>
> In libraries/adodb/drivers/adodb-postgres64.inc.php, see L913-915 and
> 950-969.
>
> There was a fix in recent versions about that, but it only use
> pg_unescape_bytea instead of a weird "eval()" block. So I guess it just
> returns the raw binary field. That would explain why we use
> pg_escape_bytea on such fields in "classes/database/Postgres.php:233".
> That was not making sense at all for me until now...
>
> PFA a quick'n'dirty patch that seems to fix the issue (with my very
> quick and trivial tests) by forbidding ADOdb to unescape bytea. It
> probably needs some more test and just force the escape format with 9.0+.
>
> AFAICS, ADOdb doe not allow to switch this behaviour off.
>
> BTW, I guess we should upgrade our ADOdb library. Thoughts about that?
>

I sort of feel that we have a private fork of ADOdb at this point, so
I'd be pretty scared to update it. Unless you think it will help solve
the bytea problem immediately in front of us, I'd at least say we put
it off till after a release.

WRT solving the bytea problem, I had a thought that the right answer
might be to use the "format" column to allow users to switch between
hex and escape. I think we can detect (or force) this information from
the server to set it initially.

That said, before we worry about that, I'd like to see it work in any
way/shape/form, so I'll be looking at your patch in just a bit to see.
If we can get it working *at all* then I think we can worry about
making it more flexible.

Robert Treat
surge.omniti.com: cfp is now open!

Re: [ppa-dev] What to do about bytea bug...

[Jehan-Guillaume (i. de R. <io...@fr...>]

On 07/03/2013 20:07, Robert Treat wrote:
> On Thu, Mar 7, 2013 at 12:15 PM, Jehan-Guillaume (ioguix) de Rorthais
> <io...@fr...> wrote:
>> On 19/02/2013 11:38, Jehan-Guillaume (ioguix) de Rorthais wrote:
>>> On 19/02/2013 02:57, Karl O. Pinc wrote:
>>>> On 02/18/2013 06:27:46 PM, Jehan-Guillaume (ioguix) de Rorthais wrote:
>>>>
>>>>> We can not know what was the original input format. So in my opinion,
>>>>> we
>>>>> should add a parameter to handle bytea_output in config.inc.php and
>>>>> make
>>>>> this a user decision. Presently, we just force it to 'hex' and
>>>>> corrupt
>>>>> it on the way. The other option is to pick 'hex' (thus, keep using
>>>>> pg_escape_bytea), but fix the way we print it.
>>>>
>>>> Hex is the canonical pg representation so IMHO we will at least
>>>> want the option to display/edit in hex.  Since we're doing
>>>> hex anyway then for the moment just do everything in hex.
>>>
>>> Yeah, we are doing 'hex' with 9.0+, but without really noticing it
>>> before now.
>>>
>>> 'hex' is the fastest format anyway. And only supporting 'hex' correctly
>>> for 9.0+ is probably the easiest and quickest patch.
>>>
>>> I might not have time to work on this before one or two weeks, but I'll
>>> try...unless someone else could jump on this issue as we have a strategy
>>> now. I'll be able to review any patch for sure.
>>
>> Back on this subject.
>>
>> While trying to find if it is possible to print bytea in "escape" format
>> under 9.0+ correctly, I found that our version of adodb is messing with
>> bytea as well. Yeah! Some more fun :)
>>
>> In libraries/adodb/drivers/adodb-postgres64.inc.php, see L913-915 and
>> 950-969.
>>
>> There was a fix in recent versions about that, but it only use
>> pg_unescape_bytea instead of a weird "eval()" block. So I guess it just
>> returns the raw binary field. That would explain why we use
>> pg_escape_bytea on such fields in "classes/database/Postgres.php:233".
>> That was not making sense at all for me until now...
>>
>> PFA a quick'n'dirty patch that seems to fix the issue (with my very
>> quick and trivial tests) by forbidding ADOdb to unescape bytea. It
>> probably needs some more test and just force the escape format with 9.0+.
>>
>> AFAICS, ADOdb doe not allow to switch this behaviour off.
>>
>> BTW, I guess we should upgrade our ADOdb library. Thoughts about that?
>>
> 
> I sort of feel that we have a private fork of ADOdb at this point, so
> I'd be pretty scared to update it.

Mh, I don't remember having patched ADOdb since last update.

> Unless you think it will help solve
> the bytea problem immediately in front of us, I'd at least say we put
> it off till after a release.

Ok. I really think we should drop it though.

> WRT solving the bytea problem, I had a thought that the right answer
> might be to use the "format" column to allow users to switch between
> hex and escape.

Yeah, I was considering this as well. The only problem about that is
that this is more than a fix, it's a full new feature. Not sure how
longer it would be to dev.
If we are taking this way (which is probably the best for everyone, but
longer to dev), it requires to add a navlink to switch between format on
simple browsing page as well.

> I think we can detect (or force) this information from
> the server to set it initially.

I don't understand what you mean. Based on the server version, we can
set the default format to use for printing values, yes. But we can not
know what was the format used by the user when the data was inserted.

> That said, before we worry about that, I'd like to see it work in any
> way/shape/form, so I'll be looking at your patch in just a bit to see.
> If we can get it working *at all* then I think we can worry about
> making it more flexible.

Great. I'm waiting for your feedback and feeling then.

> Robert Treat
> surge.omniti.com: cfp is now open!

Re: [ppa-dev] What to do about bytea bug...

[Jehan-Guillaume (i. de R. <io...@fr...>]

On 19/02/2013 11:38, Jehan-Guillaume (ioguix) de Rorthais wrote:
> On 19/02/2013 02:57, Karl O. Pinc wrote:
>> On 02/18/2013 06:27:46 PM, Jehan-Guillaume (ioguix) de Rorthais wrote:
>>
>>> We can not know what was the original input format. So in my opinion,
>>> we
>>> should add a parameter to handle bytea_output in config.inc.php and
>>> make
>>> this a user decision. Presently, we just force it to 'hex' and 
>>> corrupt
>>> it on the way. The other option is to pick 'hex' (thus, keep using
>>> pg_escape_bytea), but fix the way we print it.
>>
>> Hex is the canonical pg representation so IMHO we will at least
>> want the option to display/edit in hex.  Since we're doing
>> hex anyway then for the moment just do everything in hex.
> 
> Yeah, we are doing 'hex' with 9.0+, but without really noticing it
> before now.
> 
> 'hex' is the fastest format anyway. And only supporting 'hex' correctly
> for 9.0+ is probably the easiest and quickest patch.
> 
> I might not have time to work on this before one or two weeks, but I'll
> try...unless someone else could jump on this issue as we have a strategy
> now. I'll be able to review any patch for sure.

Back on this subject.

While trying to find if it is possible to print bytea in "escape" format
under 9.0+ correctly, I found that our version of adodb is messing with
bytea as well. Yeah! Some more fun :)

In libraries/adodb/drivers/adodb-postgres64.inc.php, see L913-915 and
950-969.

There was a fix in recent versions about that, but it only use
pg_unescape_bytea instead of a weird "eval()" block. So I guess it just
returns the raw binary field. That would explain why we use
pg_escape_bytea on such fields in "classes/database/Postgres.php:233".
That was not making sense at all for me until now...

PFA a quick'n'dirty patch that seems to fix the issue (with my very
quick and trivial tests) by forbidding ADOdb to unescape bytea. It
probably needs some more test and just force the escape format with 9.0+.

AFAICS, ADOdb doe not allow to switch this behaviour off.

BTW, I guess we should upgrade our ADOdb library. Thoughts about that?

>> Karl <ko...@me...>
>> Free Software:  "You don't pay back, you pay forward."
>>                  -- Robert A. Heinlein
>>

Re: [ppa-dev] Table action buttons not working after editing row

[Jehan-Guillaume (i. de R. <io...@fr...>]

On 03/03/2013 04:20, Ian Lawrence Barwick wrote:
> 2013/2/13 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...>:
>> On 09/02/2013 01:59, Ian Lawrence Barwick wrote:
> 
>>> I'm still trying to work out how this all fits together, so can't comment on
>>> what the best way to handle this is yet.
>>>
>>> BTW I've attached a very small patch to supress some "Undefined index"
>>> notices in the Report plugin.
>>
>> Thanks, I'll review and push as soon as possible.
> 
> Did you get a chance to look at this? I've reattached the patch.

Commited

>>> Also, can I provide an "ABOUT" file or similar to include in the Report plugin
>>> source to give a brief explanation of what it does and how to use it? It
>>> wasn't immediately obvious to me.
>>
>> Yup, please, proceed :)
> 
> See attached README file.

Commited as well :)

Thank you !

> Regards
> 
> Ian Barwick

Re: [ppa-dev] Table action buttons not working after editing row

[Ian L. B. <ba...@gm...>]

2013/2/13 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...>:
> On 09/02/2013 01:59, Ian Lawrence Barwick wrote:

>> I'm still trying to work out how this all fits together, so can't comment on
>> what the best way to handle this is yet.
>>
>> BTW I've attached a very small patch to supress some "Undefined index"
>> notices in the Report plugin.
>
> Thanks, I'll review and push as soon as possible.

Did you get a chance to look at this? I've reattached the patch.

>> Also, can I provide an "ABOUT" file or similar to include in the Report plugin
>> source to give a brief explanation of what it does and how to use it? It
>> wasn't immediately obvious to me.
>
> Yup, please, proceed :)

See attached README file.

Regards

Ian Barwick

Re: [ppa-dev] Table action buttons not working after editing row

[Ian L. B. <ba...@gm...>]

2013/2/20 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...>:
> On 20/02/2013 10:59, Ian Lawrence Barwick wrote:
>> 2013/2/19 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...>
>>>
>>> On 18/02/2013 15:01, Ian Lawrence Barwick wrote:
>>>>
>>>> 2013/2/18 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...
>>>> <mailto:io...@fr...>>
>>>>
>>>>     On 17/02/2013 00:12, Ian Lawrence Barwick wrote:
>>>>     > 2013/2/13 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...
>>>>     <mailto:io...@fr...>>:
>>>>     >> On 11/02/2013 05:29, Ian Lawrence Barwick wrote:
>>>>     >>> 2013/2/9 Ian Lawrence Barwick <ba...@gm...
>>>>     <mailto:ba...@gm...>>:
>>>>     > (...)
>>>>     >>> I've spent a bit more time looking at this and while I don't yet
>>>>     have
>>>>     >>> any concrete
>>>>     >>> suggestions, the way the link generation is being handled is
>>>>     certainly not
>>>>     >>> optimal :( It seems pretty much all the POST data is getting
>>>>     included in some
>>>>     >>> of the URLs generated after form submission.
>>>>     >>
>>>>     >> Agree, this is quite a bad patch. I hadn't check all consequences...
>>>>     >>
>>>>     >> I'll revert it.
>>>>     >>
>>>>     >>> E.g. if you edit a record on a table, after submitting the form, in
>>>>     >>> the "browse" view
>>>>     >>> the table header links to sort columns also now contain all the data
>>>>     >>> submitted from
>>>>     >>> the form.
>>>>     >>
>>>>     >> Exactly.
>>>>     >>
>>>>     >>> I'll continue looking into it, it's useful to find out how
>>>>     things fit
>>>>     >>> together anyway.
>>>>     >>
>>>>     >> I'll try to revert this patch quickly, so we can work on a
>>>>     "clean" code.
>>>>     >
>>>>     > Have you been able to revert this patch? I've got an idea for a plugin
>>>>     > I'd like to write which would be useful for me to get to know how
>>>>     > the PPA code works and what the actual issues are.
>>>>
>>>>     Not yet :/
>>>>     I hope I'll be able to deal with this during the week.
>>>>
>>>>     Stay tuned;)
>>>>
>>>>
>>>> No worries, thanks :)
>>>
>>> Committed !
>>
>> Apologies for the stupid question, but where can I see the commit?
>>
>> Is this the correct repository?
>>
>> https://github.com/phppgadmin/phppgadmin/commits/master
>
> Yes, this is the correct repo. I pushed in my own one by mistake.
>
> Main repo updated now. Here is the commit:
>
> https://github.com/phppgadmin/phppgadmin/commit/1127ff311bf8c935b566d20242bd9a003dd3e26a

Thanks:)


Ian Barwick

Re: [ppa-dev] Table action buttons not working after editing row

[Jehan-Guillaume (i. de R. <io...@fr...>]

On 20/02/2013 10:59, Ian Lawrence Barwick wrote:
> 2013/2/19 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...>
>>
>> On 18/02/2013 15:01, Ian Lawrence Barwick wrote:
>>>
>>> 2013/2/18 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...
>>> <mailto:io...@fr...>>
>>>
>>>     On 17/02/2013 00:12, Ian Lawrence Barwick wrote:
>>>     > 2013/2/13 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...
>>>     <mailto:io...@fr...>>:
>>>     >> On 11/02/2013 05:29, Ian Lawrence Barwick wrote:
>>>     >>> 2013/2/9 Ian Lawrence Barwick <ba...@gm...
>>>     <mailto:ba...@gm...>>:
>>>     > (...)
>>>     >>> I've spent a bit more time looking at this and while I don't yet
>>>     have
>>>     >>> any concrete
>>>     >>> suggestions, the way the link generation is being handled is
>>>     certainly not
>>>     >>> optimal :( It seems pretty much all the POST data is getting
>>>     included in some
>>>     >>> of the URLs generated after form submission.
>>>     >>
>>>     >> Agree, this is quite a bad patch. I hadn't check all consequences...
>>>     >>
>>>     >> I'll revert it.
>>>     >>
>>>     >>> E.g. if you edit a record on a table, after submitting the form, in
>>>     >>> the "browse" view
>>>     >>> the table header links to sort columns also now contain all the data
>>>     >>> submitted from
>>>     >>> the form.
>>>     >>
>>>     >> Exactly.
>>>     >>
>>>     >>> I'll continue looking into it, it's useful to find out how
>>>     things fit
>>>     >>> together anyway.
>>>     >>
>>>     >> I'll try to revert this patch quickly, so we can work on a
>>>     "clean" code.
>>>     >
>>>     > Have you been able to revert this patch? I've got an idea for a plugin
>>>     > I'd like to write which would be useful for me to get to know how
>>>     > the PPA code works and what the actual issues are.
>>>
>>>     Not yet :/
>>>     I hope I'll be able to deal with this during the week.
>>>
>>>     Stay tuned;)
>>>
>>>
>>> No worries, thanks :)
>>
>> Committed !
> 
> Apologies for the stupid question, but where can I see the commit?
> 
> Is this the correct repository?
> 
> https://github.com/phppgadmin/phppgadmin/commits/master

Yes, this is the correct repo. I pushed in my own one by mistake.

Main repo updated now. Here is the commit:

https://github.com/phppgadmin/phppgadmin/commit/1127ff311bf8c935b566d20242bd9a003dd3e26a

> Thanks
> 
> Ian Barwick