Jeff Davis wrote:
On Sun, 2011-06-26 at 00:57 -0700, Darren Duncan wrote:
I believe that the best general solution here is for every ordered base type to
just have a single total order, which is always used with that type in any
generic order-sensitive operation, including any ranges defined ov
Tom Lane wrote:
Darren Duncan writes:
I believe that the best general solution here is for every ordered base type to
just have a single total order, which is always used with that type in any
generic order-sensitive operation, including any ranges defined over it, or any
ORDER BY or any <,>,
Excerpts from Robert Haas's message of vie jun 24 22:22:55 -0400 2011:
> On Fri, Jun 24, 2011 at 7:47 PM, Bruce Momjian wrote:
> > You want the environment variable support removed?
>
> I don't. It's production usefulness is questionable, but it's quite
> handy for testing IMO.
If that's what
On Sat, Jun 25, 2011 at 2:15 AM, Dean Rasheed wrote:
> Really? I would expect the reverse, namely that the not-nullness is
> part of the PK constraint and dropping the PK *would* then start
> allowing NULLs.
Hmm, OK. I had assumed we were only trying to fix the problem that
parent and child inhe
Peter Eisentraut wrote:
> In the above case, you create a bunch of traps. If the user abandons
> the attempt to run pg_upgrade but leaves the shell open, comes back at
> some other time (or, say, someone else who also logs into the shared
> postgres account), and runs just "pg_upgrade" for lack of
On Mon, 2011-06-27 at 00:37 +0200, Florian Pflug wrote:
> I actually wouldn't expect there to be one. From what I gathered
> during the last discussion, the ideal behind range types is that they
> model sets of the form {x in T | a <= x < b} for arbitrary types
> T, with the only requirement being
On Mon, 2011-06-27 at 00:56 +0200, Florian Pflug wrote:
> Well, there actually *is* some precedence for that kind of top-down
> (form a syntactic perspective) type inference. We *enforce* the cast
> in
> array[]::
> and actually for a very similar reason - without the case, there's no
> way of k
On Jun26, 2011, at 00:29 , Jeff Davis wrote:
> declare the return type of a function, and then use the declared type to
> infer the argument types. That would be nice because you would just have
> to do:
> range(1,10)::int8range
> However, that's kind of backwards from how our type inference syste
Hi
Updated patch attached. Do you think this is "Ready for Committer"?
best regards,
Florian Pflug
pg_xml_errorhandling.v3.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailp
On Jun26, 2011, at 09:18 , Jeff Davis wrote:
> Currently, there is no way to define a generic "length" function over
> range types, which would give you the distance between the boundary
> points.
I actually wouldn't expect there to be one. From what I gathered
during the last discussion, the idea
On fre, 2011-06-24 at 19:47 -0400, Bruce Momjian wrote:
> > I'm wondering why pg_upgrade needs environment variables at all. It's a
> > one-shot operation. Environment variables are typically used to shared
> > default settings across programs. I don't see how that applies here.
>
> They were t
"Kevin Grittner" wrote:
> "Kevin Grittner" wrote:
>> Heikki Linnakangas wrote:
>>> BTW, isn't bitgetpage() in nodeBitmapHeapscan.c missing
>>> PredicateLockTuple() and CheckForSerializableConflictOut() calls
>>> in the codepath for a lossy bitmap? In the non-lossy case,
>>> heap_hot_search_buffe
"Kevin Grittner" wrote:
> Heikki Linnakangas wrote:
>> BTW, isn't bitgetpage() in nodeBitmapHeapscan.c missing
>> PredicateLockTuple() and CheckForSerializableConflictOut() calls
>> in the codepath for a lossy bitmap? In the non-lossy case,
>> heap_hot_search_buffer() takes care of it, but not i
On Sun, 2011-06-26 at 13:45 +0100, Greg Stark wrote:
> On Sun, Jun 26, 2011 at 8:18 AM, Jeff Davis wrote:
> > * it needs to know the result type of that function, which might not be
> > the subtype (for instance, for timestamp the difference type would be
> > interval)
>
> What's the use case fo
Hello
>
> I have touched next_token() and next_token_expand() a bit more, because
> it seemed to me that they could be simplified further (the bit about
> returning the comma in the token, instead of being a boolean return,
> seemed strange). Please let me know what you think.
>
I am thinking, s
On Sun, 2011-06-26 at 00:57 -0700, Darren Duncan wrote:
> I believe that the best general solution here is for every ordered base type
> to
> just have a single total order, which is always used with that type in any
> generic order-sensitive operation, including any ranges defined over it, or
On Fri, Jun 24, 2011 at 10:43 PM, Robert Haas wrote:
>> It's not me you block Robert, I'm not actually a user and I will sleep
>> well whatever happens, happy that I tried to resolve this. Users watch
>> and remember.
>
> If you are proposing that I should worry about a posse of angry
> PostgreSQ
Darren Duncan writes:
> I believe that the best general solution here is for every ordered base type
> to
> just have a single total order, which is always used with that type in any
> generic order-sensitive operation, including any ranges defined over it, or
> any
> ORDER BY or any <,>,etc.
Radek,
On 06/20/2011 03:27 PM, Radosław Smogura wrote:
> When playing with mmap I done some approach how to deal with growing
> files, so...
Your approach seems to require a SysV alloc (for nattach) as well as
POSIX shmem and/or mmap. Adding requirements for these syscalls
certainly needs to giv
On 25.06.2011 22:29, Kevin Grittner wrote:
In looking this over I noticed something else that doesn't seem quite
right. In heapam.c there are two places where the execution of
PredicateLockTuple() is conditioned not just on MVCC visibility, but
also on HeapKeyTest(). I think those calls should
On Sun, Jun 26, 2011 at 8:18 AM, Jeff Davis wrote:
> * it needs to know the result type of that function, which might not be
> the subtype (for instance, for timestamp the difference type would be
> interval)
What's the use case for the length() function? Is it for users to be
able to display us
On 25.06.2011 11:23, Alexander Korotkov wrote:
On Sat, Jun 25, 2011 at 11:03 AM, Jesper Krogh wrote:
* Wouldn't it be natural to measure the performance benefits of
disc-bound tests in an SSD setup?
Sure, it would be great to run performance tests on SSD drives too.
Unfortunately, I don't
I checked your patch.
The backend portion seems to me OK, but I have several questions/comments.
* This patch should be rebased.
It conflicts with the latest bin/psql/describe.c and
include/catalog/catversion.h.
IIRC, we should not touch catversion.h in submission stage. (It might
be a task of
co
Hello all,
I am returning back to discuss
http://web.archiveorange.com/archive/v/alpsnfEhA5L6HGsV2lNb
Robert introduces a global defined tables there. The talk was about
good naming - and I think, so there was agreement so name "global temp
tables" should be used for tables with persistent struct
To eludicate my earlier comments on this subject ...
I believe that the best general solution here is for every ordered base type to
just have a single total order, which is always used with that type in any
generic order-sensitive operation, including any ranges defined over it, or any
ORDER
Currently, there is no way to define a generic "length" function over
range types, which would give you the distance between the boundary
points.
It sounds simple, but the system actually needs quite a lot more
information to accomplish that:
* a function that subtracts two values of the range's
26 matches
Mail list logo
