phppgadmin-devel — For Developers Only

Re: [ppa-dev] is phpPgAdmin development still active?

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

On 31/01/2013 10:25, Ian Lawrence Barwick wrote:
> 2013/1/30 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...>:
>> 
>> The official repository is :
>> 
>> https://github.com/phppgadmin/phppgadmin/
> 
> Slightly OT, more of a general GIT question: I have several
> computers I use for development (Linux desktop, Macbook) and I'd
> like to synchronise any development work I do between them. With
> GIT, is it possible to clone the official repository to a private
> server, and commit any changes I make locally to that clone to keep
> my development computers in sync? And if so, how do I keep
> everything in sync with the official repository?

Even better, you can clone the phppgadmin repo on github and work on
your own branch in your own repo and keep it in sync in your computers.

When you think your patch is ready, you can either just make a pull
request on github so we can merge it in the official repo quickly, or
send your patch to the ml using "git format-patch" :)

> 
> Any advice much appreciated :)
> 
> Ian Barwick

Re: [ppa-dev] is phpPgAdmin development still active?

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

2013/1/30 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...>:
>
> The official repository is :
>
>   https://github.com/phppgadmin/phppgadmin/

Slightly OT, more of a general GIT question: I have several computers I use
for development (Linux desktop, Macbook) and I'd like to synchronise any
development work I do between them. With GIT, is it possible to clone
the official repository to a private server, and commit any changes I make
locally to that clone to keep my development computers in sync? And if
so, how do I keep everything in sync with the official repository?

Any advice much appreciated :)

Ian Barwick

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

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

On 01/30/2013 07:29:29 PM, Robert Treat wrote:

> While I agree that I think php itself needs some hackery; you should
> be able to work around this by toggling the bytea output style 
> itself.

Yes.  And if I _really_ knew what was wrong then I would have fixed it.
Until it's fixed it's all just talk.

> On a side note, can you resend me your functions? ISTR there was some
> reason they wouldn't work for me, but I'd like to look at them again.

Could be because they don't solve the problem?  ;-)

Here they are.

----------------<snip>------------
<?php

function raw2byteahex($r) {
  // $r   A php string containing raw bytes.
  // Returns:  A pg bytea escaped string in pg's hex representation.
  //
  // Remarks:
  // (Does not deal with "double escapeing" the \ for the parser,
  // quoting, or any of that sort of stuff.)
  //
  // Php happens to use lower case hex, as does pg.

  return '\x' . bin2hex($r);
}

function byteahex2raw($b) {
  // $b   A php string containing pg's bytea hex representation.
  //      (Assumed to be a valid representation.)
  // Returns:  A php string with raw bytes.

  // In php 5.4.0 or later we can do this.
  // Screw around comparing php versions if you so desire.
  //  return hex2bin(str_replace(' ', '', substr($b, 2)));

  return pack('H*', str_replace(' ', '', substr($b, 2)));
}

printf("%s\n", raw2byteahex(byteahex2raw('\xDEADBEEF')));

?>
----------------<snip>------------


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 Wed, Jan 30, 2013 at 10:22 AM, Karl O. Pinc <ko...@me...> wrote:
> I remember thinking that one of php's functions, probably
> pg_escape_bytea/pg_unescape_bytea does not work with pg's
> new hex binary default.  And this is why I wrote my own functions
> for this purpose and sent them to this list.
>
> In other words, php is broken, at least for newer pg releases.
>

While I agree that I think php itself needs some hackery; you should
be able to work around this by toggling the bytea output style itself.

On a side note, can you resend me your functions? ISTR there was some
reason they wouldn't work for me, but I'd like to look at them again.

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

Re: [ppa-dev] is phpPgAdmin development still active?

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

On Wed, Jan 30, 2013 at 5:32 PM, Diorman Colmenares
<dex...@gm...> wrote:
> Hi guys,
>
> I don't think the split is a problem although for new people willing to get
> involved could be just a bit confusing at first. In my opinion it would be
> nice to have everything in the same place. It's up to you, though. I would
> like to help but I just don't know where to start. I agree that creating a
> todo list is one of things the project needs the most.
>

Heh, we actually have two TODO lists :-)

The bug tracker:
https://sourceforge.net/tracker/?limit=25&func=&group_id=37132&atid=418980&assignee=&status=&category=&artgroup=&keyword=&submitter=&artifact_id=&assignee=&status=1&category=&artgroup=&submitter=&keyword=&artifact_id=&submit=Filter&mass_category=&mass_priority=&mass_resolution=&mass_assignee=&mass_artgroup=&mass_status=&mass_cannedresponse=&_visit_cookie=c98015d9201bd0f0ed148da8094482bc

(and btw, anything "assigned", feel free to claim if you want)

And one in the code:
https://github.com/phppgadmin/phppgadmin/blob/master/TODO

Either one has things people can start hacking on, if they want.


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

Re: [ppa-dev] is phpPgAdmin development still active?

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

On 01/30/2013 04:32:41 PM, Diorman Colmenares wrote:

> I
> would like to help but I just don't know where to start. I agree that
> creating a todo list is one of things the project needs the most.

The problem with a todo list is that no matter the content people
will work on whatever they want to get done.

What really needs help with at the moment is solving the bytea
bug.  That's the primary thing holding up a new release.

Regards,

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

Re: [ppa-dev] is phpPgAdmin development still active?

[Diorman C. <dex...@gm...>]

Hi guys,

I don't think the split is a problem although for new people willing to
get involved could be just a bit confusing at first. In my opinion it would
be nice to have everything in the same place. It's up to you, though. I
would like to help but I just don't know where to start. I agree that
creating a todo list is one of things the project needs the most.

Cheers

Re: [ppa-dev] is phpPgAdmin development still active?

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

On Wed, Jan 30, 2013 at 8:04 AM, Karl O. Pinc <ko...@me...> wrote:
> On 01/30/2013 04:13:43 AM, Jehan-Guillaume (ioguix) de Rorthais wrote:
>
>> I am wondering if we should move everything to github as well,
>> closing
>> our mailing lists and trackers on sf.net and only use the issue of
>> github.
>>

The current reasoning behind the split is that github didn't support
mailing list, and it's bug tracker was suspect, when we moved to
github. That's probably not really the case now. That said, if we shut
off the tracker completly, we'd lose the project history; that may not
be that valuable, but it's something to consider.

Personally I don't really have a strong preference. (Although I don't
think the split is actually a big problem for users, the lack of
manpower for the project is)

Robert Treat
play: http://xzilla.net
work: http://omniti.com

Re: [ppa-dev] is phpPgAdmin development still active?

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

On Wed, Jan 30, 2013 at 5:13 AM, Jehan-Guillaume (ioguix) de Rorthais
<io...@fr...> wrote:
> On 30/01/2013 10:36, Ian Lawrence Barwick wrote:
>>> What repository did you clone ?
>>
>> I installed the most recent release (5.0.4), as I was compiling a
>> list of PostgreSQL client applications for another project.
>
> Ok, so the PPA version you are testing is indeed quite old...but
> Sadly, it's our last release :/
>
>>>> Digging around a bit, I see the release notes only state
>>>> PostgreSQL compatibility as far as version 9.0.x, the last
>>>> release is almost a year ago, and there doesn't seem to have
>>>> been much recent repository activity.
>>>
>>> The official repository is :
>>>
>>> https://github.com/phppgadmin/phppgadmin/
>>>
>>>> I'd happily send in some patches but want to check the state
>>>> of affairs first...
>>>
>>> Yes, PPA dev is still active, but we need new developers. We
>>> already committed a bunch of patch to support 9.2 and I pretty
>>> sure that we supports 9.2 now.
>>

Just to stress, whatever you do, please don't do it against the stable
release; do it against git master.


Robert Treat
play: xzilla.net
work: omniti.com

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

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

I remember thinking that one of php's functions, probably
pg_escape_bytea/pg_unescape_bytea does not work with pg's
new hex binary default.  And this is why I wrote my own functions
for this purpose and sent them to this list.

In other words, php is broken, at least for newer pg releases.

I'm sorry but I'm crazy busy right now and can't look into
it.  It'll be a couple of weeks at least before I get
caught up.

On 01/25/2013 09:47:27 AM, Robert Treat wrote:
> On Fri, Jan 25, 2013 at 5:03 AM, Jehan-Guillaume (ioguix) de Rorthais
> <io...@fr...> wrote:
> > On 24/01/2013 19:23, Marek Černocký wrote:
> >> Robert Treat píše v Čt 24. 01. 2013 v 10:45 -0500:
> >>> On Thu, Jan 24, 2013 at 8:48 AM, Jehan-Guillaume (ioguix) de
> >>> Rorthais <io...@fr...> wrote:
> >>>> On 24/01/2013 14:32, Karl O. Pinc wrote:
> >>>>> On 01/23/2013 11:03:50 PM, Robert Treat wrote:
> >
> > [...]
> >
> >>>>> If bytea is to be displayed as something other than hex that
> >>>>> should happen in javascript on the client.
> >>>>
> >>>> Mh, you're talking about showing the content of the binary, ie.
> >>>> an image ? We're far from this consideration imo.
> >>>>
> >>>
> >>> right. we only want to show the hex output, not show actual
> >>> images. (also, consider the use case of things like hex passcodes
> >>> or similar; bytea isn't always an image).
> >>
> >> I think that users edit binary data briefly. It is essential to
> >> avoid data corruption.
> >
> > Agree.
> >
> >> What this solution: show only some info, e.g. number of bytes a
> >> provide buttons for actions as "Edit as hex", "Show as image" etc.
> >
> > Would be nice. But as Robert explained upthread, the way PPA works,
> it
> > is not possible to do this. Each time you edit a row, **all** the
> > fields are set in the update query generated by PPA.
> >
> > Moreover, it is not possible to avoid bytea on tables with NOT NULL
> > constraints on them as instance.
> >
> 
> Well, one thought I did have was to change the underlying update
> functionality to only write SQL statements that include changed
> fields, but thats tricky, and also doesn't really solve the whole
> problem.
> 
> >>> I think where the issue comes up is that when you submit the
> >>> form, there is some escaping that occurs for http purposes. PHP
> >>> is supposed to give you the tools to deal with that, and postgres
> >>> is also supposed to give you some tools for that, just that I
> >>> couldn't figure out a working combo. The form piece is
> >>> significant; ISTR that I was able to get a script to do the
> >>> select, escape, unescape, and update (where I just put back the
> >>> same value) to work successfully, it was when adding in the step
> >>> of displaying via form and then submitting that it falls apart.
> >>>
> >>> And not to be pessimistic, but I was very surprised I could find
> >>> no example PHP application that did this. Plenty of example for
> >>> reading a a file from disk and inserting it, and plenty for
> >>> pulling bytea and displaying it, but no for retrieving from db
> >>> and the updating from a form. :-\
> >>>
> 
> Attaching the script is was using for playing around... it's a bit
> messy, and not sure if the current state actually works, but 
> hopefully
> helpful.
> 
> 
> Robert Treat
> conjecture: xzilla.net
> consulting: omniti.com
> 

------quoted attachment------
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills
> current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnnow-d2d

------quoted attachment------
> _______________________________________________
> phpPgAdmin-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phppgadmin-devel
> 




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

Re: [ppa-dev] is phpPgAdmin development still active?

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

On 01/30/2013 04:13:43 AM, Jehan-Guillaume (ioguix) de Rorthais wrote:

> I am wondering if we should move everything to github as well, 
> closing
> our mailing lists and trackers on sf.net and only use the issue of
> github.
> 
> Thoughts ?

I like email.


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

Re: [ppa-dev] is phpPgAdmin development still active?

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

On 01/30/2013 03:36:01 AM, Ian Lawrence Barwick wrote:

> 
> That's good to hear, I didn't have time to look in much detail but it
> seemed everything had gone very quiet.

For reasons unknown most develper interaction seems to occur on IRC.

I prefer email so I don't have to continuously monitor
IRC traffic, but it is what it is.

Regards,

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

Re: [ppa-dev] is phpPgAdmin development still active?

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

On 30/01/2013 10:36, Ian Lawrence Barwick wrote:
> Hi Jehan-Guillaume
> 
> Thanks for the quick response :)
> 
> 2013/1/30 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...>:
>> On 30/01/2013 02:55, Ian Lawrence Barwick wrote:
>>> Hi
>> 
>> Hello Ian !
>> 
>>> I just installed phpPgAdmin in a test environment running PHP
>>> 5.4 and I'm getting a bunch of "Strict Standards" errors.
>> 
>> What repository did you clone ?
> 
> I installed the most recent release (5.0.4), as I was compiling a
> list of PostgreSQL client applications for another project.

Ok, so the PPA version you are testing is indeed quite old...but
Sadly, it's our last release :/

>>> Digging around a bit, I see the release notes only state
>>> PostgreSQL compatibility as far as version 9.0.x, the last
>>> release is almost a year ago, and there doesn't seem to have
>>> been much recent repository activity.
>> 
>> The official repository is :
>> 
>> https://github.com/phppgadmin/phppgadmin/
>> 
>>> I'd happily send in some patches but want to check the state
>>> of affairs first...
>> 
>> Yes, PPA dev is still active, but we need new developers. We
>> already committed a bunch of patch to support 9.2 and I pretty
>> sure that we supports 9.2 now.
> 
> That's good to hear, I didn't have time to look in much detail but
> it seemed everything had gone very quiet.

Well, discussions occurs on this list, so not so quiet, but not so
loudly either.

>> One big change in PPA 5.1 is the plugin architecture. It has
>> been created during the GSoC in 2011, actively reviewed and
>> tested with real case plugins in 2012 and is now committed since
>> few month. We still need to review/rewrite part of its
>> documentation on the wiki.
> 
> Do you have any details on what needs doing?

On the plugin arch itself, just the documentation for plugins devs.
However, note that we already have some plugins ready, some other to
review.

>> Another big step toward a clean and safer encoding policy has
>> been to make PPA's core UTF-8 only. Now that these bits has been
>> committed, we need to do some more cleanup.
>> 
>> You are right, we did not work that much on 5.4 issue, but IIRC,
>> we already committed some fixes.
>> 
>> We really want to release as soon as possible now, but we are 
>> currently messing with a ugly bug about Bytea corruption. See 
>> discussion there:
>> 
>> http://sourceforge.net/mailarchive/message.php?msg_id=30393431
>> 
>>> Thanks
>> 
>> Thanks to you, any help would be greatly appreciated.
> 
> OK, I can't promise anything but I'll see if there's anything I can
> do. Is there an up-to-date todo list anywhere?

Nope :/

I guess we should start by this. In the meantime, you can get our
current dev branch on github and check if you have further PHP 5.4
issue and send us patches.

There's a bunch of issues/bug/whishlist on our sourceforge tracker.

I am wondering if we should move everything to github as well, closing
our mailing lists and trackers on sf.net and only use the issue of
github.

Thoughts ?

> Regards
> 
> Ian Barwick

Re: [ppa-dev] is phpPgAdmin development still active?

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

Hi Jehan-Guillaume

Thanks for the quick response :)

2013/1/30 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...>:
> On 30/01/2013 02:55, Ian Lawrence Barwick wrote:
>> Hi
>
> Hello Ian !
>
>> I just installed phpPgAdmin in a test environment running PHP 5.4
>> and I'm getting a bunch of "Strict Standards" errors.
>
> What repository did you clone ?

I installed the most recent release (5.0.4), as I was compiling a list of
PostgreSQL client applications for another project.

>> Digging around a bit, I see the release notes only state PostgreSQL
>> compatibility as far as version 9.0.x, the last release is almost a
>> year ago, and there doesn't seem to have been much recent
>> repository activity.
>
> The official repository is :
>
>   https://github.com/phppgadmin/phppgadmin/
>
>> I'd happily send in some patches but want to check the state of
>> affairs first...
>
> Yes, PPA dev is still active, but we need new developers. We already
> committed a bunch of patch to support 9.2 and I pretty sure that we
> supports 9.2 now.

That's good to hear, I didn't have time to look in much detail but it
seemed everything had gone very quiet.

> One big change in PPA 5.1 is the plugin architecture. It has been
> created during the GSoC in 2011, actively reviewed and tested with
> real case plugins in 2012 and is now committed since few month. We
> still need to review/rewrite part of its documentation on the wiki.

Do you have any details on what needs doing?

> Another big step toward a clean and safer encoding policy has been to
> make PPA's core UTF-8 only. Now that these bits has been committed, we
> need to do some more cleanup.
>
> You are right, we did not work that much on 5.4 issue, but IIRC, we
> already committed some fixes.
>
> We really want to release as soon as possible now, but we are
> currently messing with a ugly bug about Bytea corruption. See
> discussion there:
>
>   http://sourceforge.net/mailarchive/message.php?msg_id=30393431
>
>> Thanks
>
> Thanks to you, any help would be greatly appreciated.

OK, I can't promise anything but I'll see if there's anything I can do.
Is there an up-to-date todo list anywhere?

Regards

Ian Barwick

Re: [ppa-dev] is phpPgAdmin development still active?

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

On 30/01/2013 02:55, Ian Lawrence Barwick wrote:
> Hi

Hello Ian !

> I just installed phpPgAdmin in a test environment running PHP 5.4
> and I'm getting a bunch of "Strict Standards" errors.

What repository did you clone ?

> Digging around a bit, I see the release notes only state PostgreSQL
> compatibility as far as version 9.0.x, the last release is almost a
> year ago, and there doesn't seem to have been much recent
> repository activity.

The official repository is :

  https://github.com/phppgadmin/phppgadmin/

> I'd happily send in some patches but want to check the state of
> affairs first...

Yes, PPA dev is still active, but we need new developers. We already
committed a bunch of patch to support 9.2 and I pretty sure that we
supports 9.2 now.

One big change in PPA 5.1 is the plugin architecture. It has been
created during the GSoC in 2011, actively reviewed and tested with
real case plugins in 2012 and is now committed since few month. We
still need to review/rewrite part of its documentation on the wiki.

Another big step toward a clean and safer encoding policy has been to
make PPA's core UTF-8 only. Now that these bits has been committed, we
need to do some more cleanup.

You are right, we did not work that much on 5.4 issue, but IIRC, we
already committed some fixes.

We really want to release as soon as possible now, but we are
currently messing with a ugly bug about Bytea corruption. See
discussion there:

  http://sourceforge.net/mailarchive/message.php?msg_id=30393431

> Thanks

Thanks to you, any help would be greatly appreciated.

> Ian Lawrence Barwick

[ppa-dev] is phpPgAdmin development still active?

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

Hi

I just installed phpPgAdmin in a test environment running PHP 5.4 and
I'm getting a bunch of "Strict Standards" errors. Digging around a
bit, I see the release notes only state PostgreSQL compatibility as
far as version 9.0.x, the last release is almost a year ago, and there
doesn't seem to have been much recent repository activity.

I'd happily send in some patches but want to check the state of affairs first...


Thanks

Ian Lawrence Barwick

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

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

On Fri, Jan 25, 2013 at 5:03 AM, Jehan-Guillaume (ioguix) de Rorthais
<io...@fr...> wrote:
> On 24/01/2013 19:23, Marek Černocký wrote:
>> Robert Treat píše v Čt 24. 01. 2013 v 10:45 -0500:
>>> On Thu, Jan 24, 2013 at 8:48 AM, Jehan-Guillaume (ioguix) de
>>> Rorthais <io...@fr...> wrote:
>>>> On 24/01/2013 14:32, Karl O. Pinc wrote:
>>>>> On 01/23/2013 11:03:50 PM, Robert Treat wrote:
>
> [...]
>
>>>>> If bytea is to be displayed as something other than hex that
>>>>> should happen in javascript on the client.
>>>>
>>>> Mh, you're talking about showing the content of the binary, ie.
>>>> an image ? We're far from this consideration imo.
>>>>
>>>
>>> right. we only want to show the hex output, not show actual
>>> images. (also, consider the use case of things like hex passcodes
>>> or similar; bytea isn't always an image).
>>
>> I think that users edit binary data briefly. It is essential to
>> avoid data corruption.
>
> Agree.
>
>> What this solution: show only some info, e.g. number of bytes a
>> provide buttons for actions as "Edit as hex", "Show as image" etc.
>
> Would be nice. But as Robert explained upthread, the way PPA works, it
> is not possible to do this. Each time you edit a row, **all** the
> fields are set in the update query generated by PPA.
>
> Moreover, it is not possible to avoid bytea on tables with NOT NULL
> constraints on them as instance.
>

Well, one thought I did have was to change the underlying update
functionality to only write SQL statements that include changed
fields, but thats tricky, and also doesn't really solve the whole
problem.

>>> I think where the issue comes up is that when you submit the
>>> form, there is some escaping that occurs for http purposes. PHP
>>> is supposed to give you the tools to deal with that, and postgres
>>> is also supposed to give you some tools for that, just that I
>>> couldn't figure out a working combo. The form piece is
>>> significant; ISTR that I was able to get a script to do the
>>> select, escape, unescape, and update (where I just put back the
>>> same value) to work successfully, it was when adding in the step
>>> of displaying via form and then submitting that it falls apart.
>>>
>>> And not to be pessimistic, but I was very surprised I could find
>>> no example PHP application that did this. Plenty of example for
>>> reading a a file from disk and inserting it, and plenty for
>>> pulling bytea and displaying it, but no for retrieving from db
>>> and the updating from a form. :-\
>>>

Attaching the script is was using for playing around... it's a bit
messy, and not sure if the current state actually works, but hopefully
helpful.


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

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

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

On 24/01/2013 19:23, Marek Černocký wrote:
> Robert Treat píše v Čt 24. 01. 2013 v 10:45 -0500:
>> On Thu, Jan 24, 2013 at 8:48 AM, Jehan-Guillaume (ioguix) de
>> Rorthais <io...@fr...> wrote:
>>> On 24/01/2013 14:32, Karl O. Pinc wrote:
>>>> On 01/23/2013 11:03:50 PM, Robert Treat wrote:

[...]

>>>> If bytea is to be displayed as something other than hex that
>>>> should happen in javascript on the client.
>>> 
>>> Mh, you're talking about showing the content of the binary, ie.
>>> an image ? We're far from this consideration imo.
>>> 
>> 
>> right. we only want to show the hex output, not show actual
>> images. (also, consider the use case of things like hex passcodes
>> or similar; bytea isn't always an image).
> 
> I think that users edit binary data briefly. It is essential to
> avoid data corruption.

Agree.

> What this solution: show only some info, e.g. number of bytes a
> provide buttons for actions as "Edit as hex", "Show as image" etc.

Would be nice. But as Robert explained upthread, the way PPA works, it
is not possible to do this. Each time you edit a row, **all** the
fields are set in the update query generated by PPA.

Moreover, it is not possible to avoid bytea on tables with NOT NULL
constraints on them as instance.

>> I think where the issue comes up is that when you submit the
>> form, there is some escaping that occurs for http purposes. PHP
>> is supposed to give you the tools to deal with that, and postgres
>> is also supposed to give you some tools for that, just that I
>> couldn't figure out a working combo. The form piece is
>> significant; ISTR that I was able to get a script to do the
>> select, escape, unescape, and update (where I just put back the
>> same value) to work successfully, it was when adding in the step
>> of displaying via form and then submitting that it falls apart.
>> 
>> And not to be pessimistic, but I was very surprised I could find
>> no example PHP application that did this. Plenty of example for
>> reading a a file from disk and inserting it, and plenty for
>> pulling bytea and displaying it, but no for retrieving from db
>> and the updating from a form. :-\
>> 
>> 
>> Robert Treat play: xzilla.net work: omniti.com
>> 

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

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

Robert Treat píše v Čt 24. 01. 2013 v 10:45 -0500:
> On Thu, Jan 24, 2013 at 8:48 AM, Jehan-Guillaume (ioguix) de Rorthais
> <io...@fr...> wrote:
> > On 24/01/2013 14:32, Karl O. Pinc wrote:
> >> On 01/23/2013 11:03:50 PM, Robert Treat wrote:
> >>> I spoke with ioguix a few days ago on irc about releasing a new
> >>> version of PPA, and that I had hoped to take another crack at
> >>> solving the bytea problem.
> >>
> >>
> >>> Thoughts?
> >>
> >> I'm going to have to pay attention to make sense, but this is
> >> what's at the top of my head.
> >>
> >> What makes bytea so special that it's corrupted?
> >>
> >> Why do we not display bytea as hex, and have it be edited as hex?
> >> (Why would hex cause corruption?)  Pg shows bytea as hex, for a
> >> reason: there's no way to tell what's encoded as bytea.
> >
> > If there's no HTML/js escaping messing needed with hex format, I'm
> > 100% ok with this solution. That was my feeling as expressed in my
> > previous mail : « Did you try with both bytea format ? »
> >
> 
> To answer Jehan's question, I did try both bytea formats, and tried on
> multiple versions of Postgres, but was unable to get it to work.
> Please don't let that stop you from trying again though, it's
> certainly possible I was doing it wrong.
> 
> >> If bytea is to be displayed as something other than hex that should
> >> happen in javascript on the client.
> >
> > Mh, you're talking about showing the content of the binary, ie. an
> > image ? We're far from this consideration imo.
> >
> 
> right. we only want to show the hex output, not show actual images.
> (also, consider the use case of things like hex passcodes or similar;
> bytea isn't always an image).

I think that users edit binary data briefly. It is essential to avoid
data corruption. What this solution: show only some info, e.g. number of
bytes a provide buttons for actions as "Edit as hex", "Show as image"
etc.

> I think where the issue comes up is that when you submit the form,
> there is some escaping that occurs for http purposes. PHP is supposed
> to give you the tools to deal with that, and postgres is also supposed
> to give you some tools for that, just that I couldn't figure out a
> working combo. The form piece is significant; ISTR that I was able to
> get a script to do the select, escape, unescape, and update (where I
> just put back the same value) to work successfully, it was when adding
> in the step of displaying via form and then submitting that it falls
> apart.
> 
> And not to be pessimistic, but I was very surprised I could find no
> example PHP application that did this. Plenty of example for reading a
> a file from disk and inserting it, and plenty for pulling bytea and
> displaying it, but no for retrieving from db and the updating from a
> form. :-\
> 
> 
> Robert Treat
> play: xzilla.net
> work: omniti.com
> 
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnnow-d2d
> _______________________________________________
> phpPgAdmin-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phppgadmin-devel

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

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

On 24/01/2013 16:45, Robert Treat wrote:
> On Thu, Jan 24, 2013 at 8:48 AM, Jehan-Guillaume (ioguix) de
> Rorthais <io...@fr...> wrote:
>> On 24/01/2013 14:32, Karl O. Pinc wrote:
>>> On 01/23/2013 11:03:50 PM, Robert Treat wrote:
>>>> I spoke with ioguix a few days ago on irc about releasing a
>>>> new version of PPA, and that I had hoped to take another
>>>> crack at solving the bytea problem.
>>> 
>>> 
>>>> Thoughts?
>>> 
>>> I'm going to have to pay attention to make sense, but this is 
>>> what's at the top of my head.
>>> 
>>> What makes bytea so special that it's corrupted?
>>> 
>>> Why do we not display bytea as hex, and have it be edited as
>>> hex? (Why would hex cause corruption?)  Pg shows bytea as hex,
>>> for a reason: there's no way to tell what's encoded as bytea.
>> 
>> If there's no HTML/js escaping messing needed with hex format,
>> I'm 100% ok with this solution. That was my feeling as expressed
>> in my previous mail : « Did you try with both bytea format ? »
>> 
> 
> To answer Jehan's question, I did try both bytea formats, and tried
> on multiple versions of Postgres, but was unable to get it to
> work. Please don't let that stop you from trying again though,
> it's certainly possible I was doing it wrong.
> 
>>> If bytea is to be displayed as something other than hex that
>>> should happen in javascript on the client.
>> 
>> Mh, you're talking about showing the content of the binary, ie.
>> an image ? We're far from this consideration imo.
>> 
> 
> right. we only want to show the hex output, not show actual
> images. (also, consider the use case of things like hex passcodes
> or similar; bytea isn't always an image).
> 
> I think where the issue comes up is that when you submit the form, 
> there is some escaping that occurs for http purposes. PHP is
> supposed to give you the tools to deal with that, and postgres is
> also supposed to give you some tools for that, just that I couldn't
> figure out a working combo. The form piece is significant; ISTR
> that I was able to get a script to do the select, escape, unescape,
> and update (where I just put back the same value) to work
> successfully, it was when adding in the step of displaying via form
> and then submitting that it falls apart.

Could you give us this script ? It would be a good scenario/starting
point to work on this issue with you.

> And not to be pessimistic, but I was very surprised I could find
> no example PHP application that did this. Plenty of example for
> reading a a file from disk and inserting it, and plenty for pulling
> bytea and displaying it, but no for retrieving from db and the
> updating from a form. :-\
> 
> 
> Robert Treat play: xzilla.net work: omniti.com

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

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

On Thu, Jan 24, 2013 at 8:48 AM, Jehan-Guillaume (ioguix) de Rorthais
<io...@fr...> wrote:
> On 24/01/2013 14:32, Karl O. Pinc wrote:
>> On 01/23/2013 11:03:50 PM, Robert Treat wrote:
>>> I spoke with ioguix a few days ago on irc about releasing a new
>>> version of PPA, and that I had hoped to take another crack at
>>> solving the bytea problem.
>>
>>
>>> Thoughts?
>>
>> I'm going to have to pay attention to make sense, but this is
>> what's at the top of my head.
>>
>> What makes bytea so special that it's corrupted?
>>
>> Why do we not display bytea as hex, and have it be edited as hex?
>> (Why would hex cause corruption?)  Pg shows bytea as hex, for a
>> reason: there's no way to tell what's encoded as bytea.
>
> If there's no HTML/js escaping messing needed with hex format, I'm
> 100% ok with this solution. That was my feeling as expressed in my
> previous mail : « Did you try with both bytea format ? »
>

To answer Jehan's question, I did try both bytea formats, and tried on
multiple versions of Postgres, but was unable to get it to work.
Please don't let that stop you from trying again though, it's
certainly possible I was doing it wrong.

>> If bytea is to be displayed as something other than hex that should
>> happen in javascript on the client.
>
> Mh, you're talking about showing the content of the binary, ie. an
> image ? We're far from this consideration imo.
>

right. we only want to show the hex output, not show actual images.
(also, consider the use case of things like hex passcodes or similar;
bytea isn't always an image).

I think where the issue comes up is that when you submit the form,
there is some escaping that occurs for http purposes. PHP is supposed
to give you the tools to deal with that, and postgres is also supposed
to give you some tools for that, just that I couldn't figure out a
working combo. The form piece is significant; ISTR that I was able to
get a script to do the select, escape, unescape, and update (where I
just put back the same value) to work successfully, it was when adding
in the step of displaying via form and then submitting that it falls
apart.

And not to be pessimistic, but I was very surprised I could find no
example PHP application that did this. Plenty of example for reading a
a file from disk and inserting it, and plenty for pulling bytea and
displaying it, but no for retrieving from db and the updating from a
form. :-\


Robert Treat
play: xzilla.net
work: omniti.com

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

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

On 01/24/2013 07:48:26 AM, Jehan-Guillaume (ioguix) de Rorthais wrote:
> On 24/01/2013 14:32, Karl O. Pinc wrote:

> 
> > If bytea is to be displayed as something other than hex that should
> > happen in javascript on the client.
> 
> Mh, you're talking about showing the content of the binary, ie. an
> image ? We're far from this consideration imo.

Agreed.

I'm talking about rendering as anything but hex, whether
that's as a sound or as text in the client locale.

It's something plugin-ish.  Especially because it's completely
application dependent as to how the bytea should be rendered.

--

If you're going to be looking at hex you might look at the
code I sent to the list a month or so ago which converts
in and out of hex.

Regards, 

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 24/01/2013 14:32, Karl O. Pinc wrote:
> On 01/23/2013 11:03:50 PM, Robert Treat wrote:
>> I spoke with ioguix a few days ago on irc about releasing a new 
>> version of PPA, and that I had hoped to take another crack at
>> solving the bytea problem.
> 
> 
>> Thoughts?
> 
> I'm going to have to pay attention to make sense, but this is
> what's at the top of my head.
> 
> What makes bytea so special that it's corrupted?
> 
> Why do we not display bytea as hex, and have it be edited as hex?
> (Why would hex cause corruption?)  Pg shows bytea as hex, for a
> reason: there's no way to tell what's encoded as bytea.

If there's no HTML/js escaping messing needed with hex format, I'm
100% ok with this solution. That was my feeling as expressed in my
previous mail : « Did you try with both bytea format ? »

> If bytea is to be displayed as something other than hex that should
> happen in javascript on the client.

Mh, you're talking about showing the content of the binary, ie. an
image ? We're far from this consideration imo.

> 
> That's my 2 cents.
> 
> 
> 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 24/01/2013 06:03, Robert Treat wrote:
> I spoke with ioguix a few days ago on irc about releasing a new 
> version of PPA, and that I had hoped to take another crack at
> solving the bytea problem. For those not familiar with it, the
> quick summary is that if you attempt to insert or edit bytea data
> via PPA, it will modify the data so that essentially you end up
> with corrupted data. Unfortunately, the way PPA works, just editing
> another field of a bytea row will also cause PPA to also update the
> bytea column, as we update all values for a given row when any
> value is updated.
> 
> Now, I've tried a few different methods of trying to fix this, but 
> could come up with no working set of escape and unescape options
> that would prevent this. (And as a note, it's made trickier because
> you have to support multiple encoding formats, though I came up
> with workarounds for that). At this point, I'm somewhat of the
> opinion it can't be done. Now, I'd be happy for someone else to
> take a look and show me the error of my ways, but barring that,
> I've spent the last few days trying to come up with a work-around.

I'll give it a try and come back to you.

Did you try with both bytea format ? IIRC, you thought it was a
php5-pgsql bug with bytea escaping, what about this question ?

> My initial idea was to just not allow editing of bytea data via
> PPA, but I've run into some problems there as well, for example, if
> you don't allow inserts of bytea data, then anyone who has a not
> null bytea column would never be able to insert row data into their
> table. That doesn't really seem like a good option.

Agree, it's a bad solution.

> So, barring someone figuring out a way to make this actually work,
> we need to come up with a better work-around, or I guess just
> release the next version with his bug in place. FWIW, this bug is
> in the current stable version of PPA, so we're not making things
> worse, but it's kind of frightening to know we have a subtle data
> corrupting behavior in PPA.

Agree as wel

> 
> Thoughts?
> 
> -- Robert Treat conjecture: xzilla.net consulting: omniti.com
> 

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

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

On 01/23/2013 11:03:50 PM, Robert Treat wrote:
> I spoke with ioguix a few days ago on irc about releasing a new
> version of PPA, and that I had hoped to take another crack at solving
> the bytea problem. 


> Thoughts?

I'm going to have to pay attention to make sense, but
this is what's at the top of my head.

What makes bytea so special that it's corrupted?

Why do we not display bytea as hex, and have it be edited
as hex?  (Why would hex cause corruption?)  Pg shows
bytea as hex, for a reason: there's no way to tell
what's encoded as bytea.

If bytea is to be displayed as something other than
hex that should happen in javascript on the client.

That's my 2 cents.


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