On fre, 2012-05-04 at 22:25 -0400, Bruce Momjian wrote:
> The new 9.2 GUC parameter temp_file_limit says it restricts temporary
> file usage per session, but it doesn't say what happens if a session
> needs to exceed that value --- it throws an error. Shouldn't we mention
> that?
Yes, that would
On fre, 2012-05-04 at 18:16 -0400, Bruce Momjian wrote:
> Not sure where you got 24 hours:
>
> Tues http://archives.postgresql.org/pgsql-hackers/2012-05/msg00061.php
> Wed http://archives.postgresql.org/pgsql-general/2012-05/msg00060.php
> Thur http://archives.postgresql.org/pgsql-commit
On fre, 2012-05-04 at 18:25 -0400, Tom Lane wrote:
> What's the grounds for asserting they were known not to work? Not
> actual testing, I assume.
There were either essential pieces missing (e.g., no shared library
support, or no Makefile.port), or we had received reports in the past
the platform
On fre, 2012-05-04 at 13:43 -0400, Robert Haas wrote:
> For this particular case, I think you just need some place to store a
> pg_type -> pg_proc mapping. I'm not exactly sure how to make that not
> a JSON-specific hack, since I certainly don't think we'd want to add a
> new catalog just for that
On fre, 2012-05-04 at 12:30 -0400, Andrew Dunstan wrote:
> Yeah, what I've been thinking about in conjunction with similar
> problems is some sort of type registry, so that we could code for
> non-builtin types in certain cases.
It certainly seems to come up a lot, but I'm not sure whether the two
On fre, 2012-05-04 at 15:59 -0400, Robert Haas wrote:
> > Can we at least have the xxx_to_json() functions try cast to json
> first
> > and fall back to text if the cast fails.
>
> I think the idea that you can involve the casting machinery in this is
> misguided. sometextval::json has got to mea
On Sat, May 05, 2012 at 11:59:54AM +0300, Peter Eisentraut wrote:
> On fre, 2012-05-04 at 18:25 -0400, Tom Lane wrote:
> > What's the grounds for asserting they were known not to work? Not
> > actual testing, I assume.
>
> There were either essential pieces missing (e.g., no shared library
> supp
On Fri, May 04, 2012 at 08:46:28PM +0300, Peter Eisentraut wrote:
> On tor, 2012-05-03 at 15:47 -0400, Bruce Momjian wrote:
> > Peter, where are we on this?
>
> I hadn't received any clear feedback, but if no one objects, I can
> commit it.
I think there were enough people that wanted some kind o
On Sat, 2012-05-05 at 12:16 +0300, Peter Eisentraut wrote:
> On fre, 2012-05-04 at 15:59 -0400, Robert Haas wrote:
> > > Can we at least have the xxx_to_json() functions try cast to json
> > first
> > > and fall back to text if the cast fails.
> >
> > I think the idea that you can involve the cast
Peter Eisentraut writes:
> On fre, 2012-05-04 at 18:25 -0400, Tom Lane wrote:
>> Furthermore, I would want to insist that a complainer provide a
>> buildfarm member as the price of us continuing to support an old
>> uncommon platform. Otherwise the apparent support is hollow. The BSDI
>> port wa
On Sat, May 05, 2012 at 11:26:32AM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On fre, 2012-05-04 at 18:25 -0400, Tom Lane wrote:
> >> Furthermore, I would want to insist that a complainer provide a
> >> buildfarm member as the price of us continuing to support an old
> >> uncommon platf
Hannu Krosing writes:
> CAST is something that should convert one type to another, in this case
> a textual type to its "json value" representation and back.
> 'sometext'::text::json --> '"sometext"'
> and
> '"sometext"'::json::text --> 'sometext'
Well, that's a pretty interesting example, becau
Bruce Momjian writes:
> On Sat, May 05, 2012 at 11:26:32AM -0400, Tom Lane wrote:
>> Possibly. What exactly is the difference between the "sco" and
>> "unixware" ports, anyway? The one buildfarm member we have running
>> SCO software (koi) chooses the unixware template.
> Unixware was based on
On 5 May 2012 09:59, Peter Eisentraut wrote:
> Based on these emerging criteria, should we also remove the other
> platforms on my original "marginal" list?
>
> irix
Well, there hasn't been an IRIX release since 2006, and silicon
graphics is defunct. The SGI brand lives on, though I think that th
On Sat, May 05, 2012 at 12:08:00PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Sat, May 05, 2012 at 11:26:32AM -0400, Tom Lane wrote:
> >> Possibly. What exactly is the difference between the "sco" and
> >> "unixware" ports, anyway? The one buildfarm member we have running
> >> SCO sof
On Sat, Apr 28, 2012 at 4:00 AM, Robert Haas wrote:
> On Fri, Apr 27, 2012 at 2:48 PM, Tom Lane wrote:
>> I'm not necessarily opposed to commandeering the name "smart" for the
>> new behavior, so that what we have to find a name for is the old "smart"
>> behavior. How about
>>
>> slow
On Sat, May 05, 2012 at 12:08:00PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Sat, May 05, 2012 at 11:26:32AM -0400, Tom Lane wrote:
> >> Possibly. What exactly is the difference between the "sco" and
> >> "unixware" ports, anyway? The one buildfarm member we have running
> >> SCO sof
On 04/05/12 20:00, Jan Urbański wrote:
On 03/05/12 11:04, Jan Urbański wrote:
On 02/05/12 20:18, Peter Eisentraut wrote:
This doesn't work anymore with Python 3:
rv = plpy.execute(...)
do_something(rv[0:1])
Sounds ugly. I'll take a look.
I found some instructions on how to deal with the Py
On Sat, May 5, 2012 at 12:44 PM, Bruce Momjian wrote:
> Well, absent user feedback, we could use our own 5-year rule and keep
> sco and unixware, and remove irix (2006).
I think we should err on the side of removing less rather than more.
It won't hurt anything much to leave these around for anot
On 6 May 2012 01:06, Robert Haas wrote:
> On Sat, May 5, 2012 at 12:44 PM, Bruce Momjian wrote:
>> Well, absent user feedback, we could use our own 5-year rule and keep
>> sco and unixware, and remove irix (2006).
>
> I think we should err on the side of removing less rather than more.
> It won't
20 matches
Mail list logo
