On Wed, May 19, 2010 1:31 pm, Tom Lane wrote:
> BTW, standard_conforming_strings is really a different case because of
> the SQL-injection security hazards with non-scs-aware client code.
> I don't see any comparable risk for bytea format.
>
Yeah, and the impact of this will be much more limited.
Magnus Hagander writes:
> On Wed, May 19, 2010 at 11:11 AM, Robert Haas wrote:
>> Yeah, that's what I'm worried about. I remember going through this
>> with E'' quoting. It wasn't fun.
> Right. So do we know what the policy is? As long as DBD::Pg is
> released before pg 9.0 we'd be fine, *prov
On May 19, 2010, at 18:32 , Robert Haas wrote:
> On Wed, May 19, 2010 at 12:16 PM, Stefan Kaltenbrunner
> wrote:
>>> I think it just depends on whether we're likely to get releases from
>>> Linux vendors that include PG 9.0 but not the updated drivers. I'm
>>> not sure their schedule will be affe
On 05/19/2010 12:32 PM, Robert Haas wrote:
> On Wed, May 19, 2010 at 12:16 PM, Stefan Kaltenbrunner
> wrote:
>>> I think it just depends on whether we're likely to get releases from
>>> Linux vendors that include PG 9.0 but not the updated drivers. I'm
>>> not sure their schedule will be affected
On Wed, May 19, 2010 at 12:16 PM, Stefan Kaltenbrunner
wrote:
>> I think it just depends on whether we're likely to get releases from
>> Linux vendors that include PG 9.0 but not the updated drivers. I'm
>> not sure their schedule will be affected by whether we call it 8.5 or
>> 9.0.
>
> that's a
On 05/19/2010 11:19 AM, Magnus Hagander wrote:
> On Wed, May 19, 2010 at 11:11 AM, Robert Haas wrote:
>> On Wed, May 19, 2010 at 11:07 AM, Magnus Hagander
>> wrote:
>>> On Wed, May 19, 2010 at 11:06 AM, Greg Sabino Mullane
>>> wrote:
>> given how much faster the new format is (or rath
On 05/19/2010 11:45 AM, Robert Haas wrote:
> On Wed, May 19, 2010 at 11:31 AM, Alex Hunsaker wrote:
>> On Wed, May 19, 2010 at 09:05, Robert Haas wrote:
>>> On Wed, May 19, 2010 at 11:00 AM, Kenneth Marshall wrote:
Changing something like that within the minor release arc is
not a good
On Wed, May 19, 2010 at 11:31 AM, Alex Hunsaker wrote:
> On Wed, May 19, 2010 at 09:05, Robert Haas wrote:
>> On Wed, May 19, 2010 at 11:00 AM, Kenneth Marshall wrote:
>>> Changing something like that within the minor release arc is
>>> not a good idea. It would be better to have it on by defaul
On Wed, May 19, 2010 at 09:05, Robert Haas wrote:
> On Wed, May 19, 2010 at 11:00 AM, Kenneth Marshall wrote:
>> Changing something like that within the minor release arc is
>> not a good idea. It would be better to have it on by default and
>> if the driver developers are not up to use it, they
On Wed, May 19, 2010 at 11:11 AM, Robert Haas wrote:
> On Wed, May 19, 2010 at 11:07 AM, Magnus Hagander wrote:
>> On Wed, May 19, 2010 at 11:06 AM, Greg Sabino Mullane
>> wrote:
>>>
> given how much faster the new format is (or rather how slow the old one
> was) and the number of peopl
* Magnus Hagander [100519 11:08]:
> How do the distros generaly deal with that? E.g. do we have to wait
> for RHEL7 for it to actually show up in redhat?
Don't worry, 9.0 won't show up in redhat for a while yet either...
;-)
--
Aidan Van Dyk Create
On Wed, May 19, 2010 at 11:07 AM, Magnus Hagander wrote:
> On Wed, May 19, 2010 at 11:06 AM, Greg Sabino Mullane
> wrote:
>>
given how much faster the new format is (or rather how slow the old one
was) and the number of people I have seen complaining "why is bytea so
slow) I would
On Wed, May 19, 2010 at 11:06 AM, Greg Sabino Mullane wrote:
>
>>> given how much faster the new format is (or rather how slow the old one
>>> was) and the number of people I have seen complaining "why is bytea so
>>> slow) I would like to see it staying turned on by default. However this
>>> also
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
>> given how much faster the new format is (or rather how slow the old one
>> was) and the number of people I have seen complaining "why is bytea so
>> slow) I would like to see it staying turned on by default. However this
>> also depends on ho
On Wed, May 19, 2010 at 11:00 AM, Kenneth Marshall wrote:
> On Wed, May 19, 2010 at 10:54:01AM -0400, Robert Haas wrote:
>> On Wed, May 19, 2010 at 10:17 AM, Stefan Kaltenbrunner
>> wrote:
>> > On 05/19/2010 08:13 AM, Tom Lane wrote:
>> >> Bernd Helmle writes:
>> >>> --On 18. Mai 2010 23:20:26 +
On Wed, May 19, 2010 at 10:54:01AM -0400, Robert Haas wrote:
> On Wed, May 19, 2010 at 10:17 AM, Stefan Kaltenbrunner
> wrote:
> > On 05/19/2010 08:13 AM, Tom Lane wrote:
> >> Bernd Helmle writes:
> >>> --On 18. Mai 2010 23:20:26 +0200 Jesper Krogh wrote:
> May I ask whats the reason is for
On Wed, May 19, 2010 at 10:17 AM, Stefan Kaltenbrunner
wrote:
> On 05/19/2010 08:13 AM, Tom Lane wrote:
>> Bernd Helmle writes:
>>> --On 18. Mai 2010 23:20:26 +0200 Jesper Krogh wrote:
May I ask whats the reason is for "breaking" the compatibillity?
>>
>>> "Efficency", if i am allowed to ca
On 05/19/2010 08:13 AM, Tom Lane wrote:
> Bernd Helmle writes:
>> --On 18. Mai 2010 23:20:26 +0200 Jesper Krogh wrote:
>>> May I ask whats the reason is for "breaking" the compatibillity?
>
>> "Efficency", if i am allowed to call it this way. The new hex
>> representation should be more efficie
Bernd Helmle writes:
> --On 18. Mai 2010 23:20:26 +0200 Jesper Krogh wrote:
>> May I ask whats the reason is for "breaking" the compatibillity?
> "Efficency", if i am allowed to call it this way. The new hex
> representation should be more efficient to retrieve and to handle than the
> old one
On Tue, May 18, 2010 at 03:26:17PM -0600, Alex Hunsaker wrote:
> On Tue, May 18, 2010 at 15:20, Jesper Krogh wrote:
> > On 2010-05-18 23:12, Alex Hunsaker wrote:
> >>
> >> set bytea_output 'escape';
> >
> > That was it. Knowing what the problem was I had no problem finding it in the
> > release no
--On 18. Mai 2010 23:20:26 +0200 Jesper Krogh wrote:
That was it. Knowing what the problem was I had no problem finding it in
the release notes.
May I ask whats the reason is for "breaking" the compatibillity?
"Efficency", if i am allowed to call it this way. The new hex
representation sh
On Tue, May 18, 2010 at 15:20, Jesper Krogh wrote:
> On 2010-05-18 23:12, Alex Hunsaker wrote:
>>
>> set bytea_output 'escape';
>
> That was it. Knowing what the problem was I had no problem finding it in the
> release notes.
>
> May I ask whats the reason is for "breaking" the compatibillity?
Th
On 2010-05-18 23:12, Alex Hunsaker wrote:
set bytea_output 'escape';
That was it. Knowing what the problem was I had no problem finding it in
the release notes.
May I ask whats the reason is for "breaking" the compatibillity?
--
Jesper
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
On Tue, May 18, 2010 at 14:54, Jesper Krogh wrote:
> Hi.
>
> I'm trying to do a test move of one of our applications onto 9.0beta1.
> We use storable and serializes data into a bytea column in the database.
> [ snip insert/select using bytea ]
> 8.4
> id | t
Hi.
I'm trying to do a test move of one of our applications onto 9.0beta1.
We use storable and serializes data into a bytea column in the database.
This script uses that:
#!/usr/bin/perl
use strict;
use warnings;
use Storable;
use DBI;
use DBD::Pg;
use Data::Dumper;
my $dbh = DBI->connect("dbi:
25 matches
Mail list logo
