On 10/01/2014 02:47 PM, Marko Tiikkaja wrote:
On 10/1/14 1:01 PM, Heikki Linnakangas wrote:
I think this is now ready for commit, but since I've changed it quite
significantly from what you originally submitted, please take a moment
to review this.
1) I see this compiler warning:
pg
On 10/1/14 1:01 PM, Heikki Linnakangas wrote:
On 10/01/2014 11:58 AM, Marko Tiikkaja wrote:
On 10/1/14, 9:11 AM, Heikki Linnakangas wrote:
We have two options:
1. Throw an error if there are any non-ASCII characters in the key/value
arrays.
2. Don't convert them to UTF-8, but use the current d
On 10/01/2014 11:58 AM, Marko Tiikkaja wrote:
On 10/1/14, 9:11 AM, Heikki Linnakangas wrote:
We have two options:
1. Throw an error if there are any non-ASCII characters in the key/value
arrays.
2. Don't convert them to UTF-8, but use the current database encoding.
Both seem sane to me. If we
On 10/1/14, 9:11 AM, Heikki Linnakangas wrote:
I spent a little time cleaning up the regression tests and docs, and
ended up with the attached. But then I realized that there's a problem
with UTF-8 conversion in the armor() function. It returns the armored
blob as text, but forcibly converts the
On 09/30/2014 06:39 PM, Marko Tiikkaja wrote:
On 9/30/14 5:17 PM, Heikki Linnakangas wrote:
I'm actually now leaning towards providing just a single function,
pgp_armor_headers(text, key OUT text, value OUT text), which returns all
the keys and values. That gives maximum flexibility, and leaves
On 9/30/14 5:17 PM, Heikki Linnakangas wrote:
I'm actually now leaning towards providing just a single function,
pgp_armor_headers(text, key OUT text, value OUT text), which returns all
the keys and values. That gives maximum flexibility, and leaves it up to
the user to decide what to do with dup
On 09/30/2014 05:45 PM, Marko Tiikkaja wrote:
On 9/30/14 4:37 PM, Heikki Linnakangas wrote:
On 09/29/2014 05:38 PM, Marko Tiikkaja wrote:
Maybe I just suck at $SEARCH_ENGINE, but extracting armor headers
programmatically doesn't seem to be very popular. I could only find one
example, which ret
Heikki Linnakangas wrote:
Happened to land on the middle of the regression test by accident and
noticed:
> +select armor('zooka', array['Version', 'Comment'], array['Created by
> pgcrypto', 'PostgreSQL, the world''s most most advanced open source
> database']);
> +
On 9/30/14 4:37 PM, Heikki Linnakangas wrote:
On 09/29/2014 05:38 PM, Marko Tiikkaja wrote:
Maybe I just suck at $SEARCH_ENGINE, but extracting armor headers
programmatically doesn't seem to be very popular. I could only find one
example, which returned the last instance of the key. But that s
On 09/29/2014 05:38 PM, Marko Tiikkaja wrote:
On 9/29/14 3:02 PM, Heikki Linnakangas wrote:
Is there any real life examples or tools out there to generate armors
with headers with duplicate keys? RFC 4880 says:
Note that some transport methods are sensitive to line length. While
the
On 9/29/14 3:02 PM, Heikki Linnakangas wrote:
Thanks! I found the pgp_extract_armor_headers()'s signature quite weird,
so I simplified that by making it always return arrays of keys and
values. The callers is now responsible for returning all the keys
(pgp_armor_header_keys) or finding the single
On 09/27/2014 11:50 PM, Marko Tiikkaja wrote:
Hi,
On 9/25/14, 3:56 PM, I wrote:
On 9/25/14 3:50 PM, Heikki Linnakangas wrote:
Are you planning to post the main patch rebased on top of this soon? As
in the next day or two? Otherwise I'll mark this as "Returned with
feedback" for this commitfest
Hi,
On 9/25/14, 3:56 PM, I wrote:
On 9/25/14 3:50 PM, Heikki Linnakangas wrote:
Are you planning to post the main patch rebased on top of this soon? As
in the next day or two? Otherwise I'll mark this as "Returned with
feedback" for this commitfest.
Yes. With good luck I'll get you a rebased
On 9/25/14 4:08 PM, Heikki Linnakangas wrote:
On 09/25/2014 04:56 PM, Marko Tiikkaja wrote:
On 9/25/14 3:50 PM, Heikki Linnakangas wrote:
On 09/10/2014 04:35 PM, Marko Tiikkaja wrote:
It might've been a tad more efficient to return
the StringInfo buffer directly from pgp_armor/dearmor, and avoi
On 09/25/2014 04:56 PM, Marko Tiikkaja wrote:
On 9/25/14 3:50 PM, Heikki Linnakangas wrote:
On 09/10/2014 04:35 PM, Marko Tiikkaja wrote:
It might've been a tad more efficient to return
the StringInfo buffer directly from pgp_armor/dearmor, and avoid the
extra palloc and memcpy, but this isn't p
On 9/25/14 3:50 PM, Heikki Linnakangas wrote:
On 09/10/2014 04:35 PM, Marko Tiikkaja wrote:
OK, I've attemped to do that in the attached. I'm pretty sure I didn't
get all of the overflows right, so someone should probably take a really
good look at it. (I'm not too confident the original code
On 09/10/2014 04:35 PM, Marko Tiikkaja wrote:
On 9/10/14 1:38 PM, Heikki Linnakangas wrote:
On 09/10/2014 02:26 PM, Marko Tiikkaja wrote:
So I wonder if I shouldn't try and instead keep the
code closer to what it is in HEAD right now; I could call
enlargeStringInfo() first, then hand out a poin
On 09/10/2014 04:35 PM, Marko Tiikkaja wrote:
Speaking of good looks, should I add it to the next commitfest as a new
patch, or should we try and get someone to review it like this?
Let's handle this in this commitfest.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
On 9/10/14 1:38 PM, Heikki Linnakangas wrote:
On 09/10/2014 02:26 PM, Marko Tiikkaja wrote:
So I wonder if I shouldn't try and instead keep the
code closer to what it is in HEAD right now; I could call
enlargeStringInfo() first, then hand out a pointer to b64_encode (or
b64_decode()) and finally
On 09/10/2014 02:26 PM, Marko Tiikkaja wrote:
On 9/9/14 11:01 AM, I wrote:
On 9/9/14 10:54 AM, Heikki Linnakangas wrote:
So I think this (and the corresponding dearmor code too) should be
refactored to use a StringInfo that gets enlarged as needed, instead of
hoping to guess the size correctly
On 9/9/14 11:01 AM, I wrote:
On 9/9/14 10:54 AM, Heikki Linnakangas wrote:
So I think this (and the corresponding dearmor code too) should be
refactored to use a StringInfo that gets enlarged as needed, instead of
hoping to guess the size correctly beforehand. To ease review, might
make sense to
On 9/9/14 10:54 AM, Heikki Linnakangas wrote:
So I think this (and the corresponding dearmor code too) should be
refactored to use a StringInfo that gets enlarged as needed, instead of
hoping to guess the size correctly beforehand. To ease review, might
make sense to do that as a separate patch o
On 08/15/2014 11:55 AM, Marko Tiikkaja wrote:
Hi,
On 8/8/14 3:18 PM, I wrote:
Currently there's no way to generate or extract armor headers from the
PGP armored format in pgcrypto. I've written a patch to add the
support.
Latest version of the patch here, having fixed some small coding issue
Marko, et al,
This is a review of the pgcrypto PGP Armor Headers patch:
http://www.postgresql.org/message-id/53edcae8.20...@joh.to
Contents & Purpose
==
This patch add functions to create and extract OpenPGP Armor Headers.
from OpenPGP messages.
Included in the patch are updated
On Fri, Aug 15, 2014 at 1:55 AM, Marko Tiikkaja wrote:
> Hi,
>
>
> On 8/8/14 3:18 PM, I wrote:
>
>> Currently there's no way to generate or extract armor headers from the
>> PGP armored format in pgcrypto. I've written a patch to add the
>> support.
>>
>
> Latest version of the patch here, havin
Hi,
On 8/8/14 3:18 PM, I wrote:
Currently there's no way to generate or extract armor headers from the
PGP armored format in pgcrypto. I've written a patch to add the
support.
Latest version of the patch here, having fixed some small coding issues.
.marko
*** a/contrib/pgcrypto/Makefile
---
Hi,
Currently there's no way to generate or extract armor headers from the
PGP armored format in pgcrypto. I've written a patch to add the
support. For example:
local:marko=#* select armor('zooka', array['Version', 'Comment'],
array['Created by pgcrypto', 'PostgreSQL, the database']);
27 matches
Mail list logo
