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
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
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
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
On 25.06.2011 11:23, Alexander Korotkov wrote:
On Sat, Jun 25, 2011 at 11:03 AM, Jesper Kroghjes...@krogh.cc 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.
On Sun, Jun 26, 2011 at 8:18 AM, Jeff Davis pg...@j-davis.com 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
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
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 give
Darren Duncan dar...@darrenduncan.net 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
On Fri, Jun 24, 2011 at 10:43 PM, Robert Haas robertmh...@gmail.com 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
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
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, so it
On Sun, 2011-06-26 at 13:45 +0100, Greg Stark wrote:
On Sun, Jun 26, 2011 at 8:18 AM, Jeff Davis pg...@j-davis.com 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
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 in the
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_buffer() takes care of
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 there in
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 ideal
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:
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 system
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[]::arraytype
and actually for a very similar reason - without the case, there's no
way
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 that
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 a
On Sat, Jun 25, 2011 at 2:15 AM, Dean Rasheed dean.a.rash...@gmail.com 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
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 br...@momjian.us 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
Tom Lane wrote:
Darren Duncan dar...@darrenduncan.net 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
25 matches
Mail list logo
