On Mon, Dec 30, 2013 at 6:02 PM, Amit Kapila wrote:
> On Sun, Dec 29, 2013 at 2:06 AM, David Rowley
> wrote:
> > On Sun, Dec 29, 2013 at 2:29 AM, Amit Kapila
> > wrote:
> >>
> >> When I tried with your patch on windows, it results into following:
> >>
> >> == running regression test
On Sun, Dec 29, 2013 at 2:06 AM, David Rowley wrote:
> On Sun, Dec 29, 2013 at 2:29 AM, Amit Kapila
> wrote:
>>
>> When I tried with your patch on windows, it results into following:
>>
>> == running regression test queries==
>> test tablespace ... di
On Sun, Dec 29, 2013 at 8:18 AM, Heikki Linnakangas
wrote:
>> My position is not based on a gut feeling. It is based on carefully
>> considering the interactions of the constituent parts, plus the
>> experience of actually building a working prototype.
>
>
> I also carefully considered all that st
On Sun, Dec 22, 2013 at 07:51:55PM +0900, MauMau wrote:
> From: "Noah Misch"
> >Better to attack that directly. Arrange to apply any
> >client_encoding named in
> >the startup packet earlier, before authentication. This relates
> >to the TODO
> >item "Let the client indicate character encoding o
On 12/28/2013 06:28 PM, Mohsen SM wrote:
> I create type based on varlena.
> I want control it that don't toast.
In general it's probably going to be better to just specify the storage
option on a column by column basis:
ALTER TABLE ... ALTER COLUMN ... SET STORAGE PLAIN;
A quick look at the sou
On 12/30/2013 08:49 AM, Craig Ringer wrote:
> One of the big appeals of the new COLLATE feature was, to me, the
> possibility that we'd be able to support custom collations including
> case-insensitive collations in future.
>
> It's something I'd like to tackle one day, and in the mean time want t
One of the big appeals of the new COLLATE feature was, to me, the
possibility that we'd be able to support custom collations including
case-insensitive collations in future.
It's something I'd like to tackle one day, and in the mean time want to
pop on the TODO so it's not lost and forgotten. Ever
On Dec26, 2013, at 21:30 , Florian Pflug wrote:
> On Dec23, 2013, at 18:39 , Peter Eisentraut wrote:
>> On 12/19/13, 6:40 PM, Florian Pflug wrote:
>>> The following example fails for XMLOPTION set to DOCUMENT as well as for
>>> XMLOPTION set to CONTENT.
>>>
>>> select xmlconcat(
>>> xmlparse(
Tom Lane wrote:
> Kevin Grittner writes:
>> Tom Lane wrote:
>>> So I'm inclined to propose that we set min/max to 0 and 99
>>> here.
>>
>> Something like the attached back-patched to 8.4?
>
> Works for me.
Done.
Thanks for the report, Joel!
--
Kevin Grittner
EDB: http://www.enterprisedb.c
On Sun, Dec 29, 2013 at 8:44 AM, knizhnik wrote:
> create function volume(r base_table) returns integer as $$ begin return
> r.x*r.y; end; $$ language plpgsql strict stable;
> create function volume(r derived_table) returns integer as $$ begin return
> r.x*r.y*r.z; end; $$ language plpgsql strict
I wrote:
> Perhaps though we should override Autoconf's setting of
> _DARWIN_USE_64_BIT_INODE, if we can do that easily? It's clearly
> not nearly as problem-free on 10.5 as the Autoconf boys believe,
> and it's already enabled by default on the release series where it
> does work.
I looked into
Kevin Grittner writes:
> Tom Lane wrote:
>> So I'm inclined to propose that we set min/max to 0 and 99 here.
> Something like the attached back-patched to 8.4?
Works for me.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
Tom Lane wrote:
> On reflection, I'm not sure that pg_restore as such should be applying any
> server version check at all. pg_restore itself has precious little to do
> with whether there will be a compatibility problem; that's mostly down to
> the DDL that pg_dump put into the archive file. A
On 12/27/2013 07:11 AM, Peter Geoghegan wrote:
On Thu, Dec 26, 2013 at 5:58 PM, Robert Haas wrote:
While mulling this over further, I had an idea about this: suppose we
marked the tuple in some fashion that indicates that it's a promise
tuple. I imagine an infomask bit, although the concept ma
Is there any chance to implement polymorphic calls in PostgreSQL?
Consider the following definitions:
create table base_table (x integer, y integer);
create table derived_table (z integer) inherits (base_table);
create function volume(r base_table) returns integer as $$ begin return
r.x*r.y; end
On 12/26/2013 01:27 AM, Peter Geoghegan wrote:
On Wed, Dec 25, 2013 at 6:25 AM, Andres Freund wrote:
And yes, I still think that promise tuples might be a better solution
regardless of the issues you mentioned, but you know what? That doesn't
matter. Me thinking it's the better approach is prim
16 matches
Mail list logo
