On Wed, Jan 12, 2011 at 2:16 AM, Martijn van Oosterhout
klep...@svana.org wrote:
On Tue, Jan 11, 2011 at 09:24:08PM -0500, Robert Haas wrote:
commit 6c412f0605afeb809014553ff7ad28cf9ed5526b
Author: Tom Lane t...@sss.pgh.pa.us
Date: Sun May 1 18:56:19 2005 +
Change CREATE TYPE to
On Jan 12, 2011, at 8:48 AM, Robert Haas wrote:
I guess that begs the question of why we need to allow users to call
type output functions directly.
I've used them quite a lot in the past; less so on 8.4+ where casting
everything to text became a lot easier.
Best,
David
--
Sent via
Excerpts from Robert Haas's message of mié ene 12 13:48:27 -0300 2011:
I guess that begs the question of why we need to allow users to call
type output functions directly.
It used to be the case that that was the only way to run certain casts.
For example, see the pre-8.2 version of this:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Robert Haas's message of mié ene 12 13:48:27 -0300 2011:
I guess that begs the question of why we need to allow users to call
type output functions directly.
It used to be the case that that was the only way to run certain
On Wed, Jan 12, 2011 at 2:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Robert Haas's message of mié ene 12 13:48:27 -0300 2011:
I guess that begs the question of why we need to allow users to call
type output functions directly.
It
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 12, 2011 at 2:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The general point is that any out-of-band data transmitted to an output
function has to be trustworthy, and it has to be available at any place
that is going to call the output
On Wed, Jan 12, 2011 at 2:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 12, 2011 at 2:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The general point is that any out-of-band data transmitted to an output
function has to be trustworthy, and it has
On Sun, Jan 9, 2011 at 4:03 AM, Jeff Davis pg...@j-davis.com wrote:
It also might be worth figuring out why input functions get the type oid
and output functions do not. I see this comment above getTypeIOParam():
* As of PostgreSQL 8.1, output functions receive only the value
itself
* and
On Tue, Jan 11, 2011 at 09:24:08PM -0500, Robert Haas wrote:
commit 6c412f0605afeb809014553ff7ad28cf9ed5526b
Author: Tom Lane t...@sss.pgh.pa.us
Date: Sun May 1 18:56:19 2005 +
Change CREATE TYPE to require datatype output and send functions to have
only one argument. (Per
On Sat, 2011-01-08 at 21:58 -0500, Robert Haas wrote:
I mean, one semi-obvious possibility is to write one set of C
functions that can have multiple SQL-level definitions bound to it.
Then when the function is called, it can peek at flinfo-fn_oid to
figure out which incarnation was called and
When writing the generic range output function, it needs to know the
specific range type in order to call the subtype's output function.
Records accomplish this by using a special cache based on the typmod,
apparently, which looks like a hack to me.
Arrays accomplish this by storing the specific
On Sat, Jan 8, 2011 at 3:12 PM, Jeff Davis pg...@j-davis.com wrote:
Any ideas? Maybe, with alignment and a flags byte (to hold
inclusivity, infinite boundaries, etc.), the extra 4 bytes doesn't cost
much, anyway?
I'd be really reluctant to bloat the range representation by 4 bytes
to support
On Sat, 2011-01-08 at 15:47 -0500, Robert Haas wrote:
On Sat, Jan 8, 2011 at 3:12 PM, Jeff Davis pg...@j-davis.com wrote:
Any ideas? Maybe, with alignment and a flags byte (to hold
inclusivity, infinite boundaries, etc.), the extra 4 bytes doesn't cost
much, anyway?
I'd be really
On Sat, 2011-01-08 at 13:05 -0800, Jeff Davis wrote:
On Sat, 2011-01-08 at 15:47 -0500, Robert Haas wrote:
On Sat, Jan 8, 2011 at 3:12 PM, Jeff Davis pg...@j-davis.com wrote:
Any ideas? Maybe, with alignment and a flags byte (to hold
inclusivity, infinite boundaries, etc.), the extra 4
On Sat, Jan 8, 2011 at 4:05 PM, Jeff Davis pg...@j-davis.com wrote:
On Sat, 2011-01-08 at 15:47 -0500, Robert Haas wrote:
On Sat, Jan 8, 2011 at 3:12 PM, Jeff Davis pg...@j-davis.com wrote:
Any ideas? Maybe, with alignment and a flags byte (to hold
inclusivity, infinite boundaries, etc.),
On Sat, Jan 8, 2011 at 6:06 PM, Jeff Davis pg...@j-davis.com wrote:
If we use timestamps, then that's 8 bytes each, meaning 16 bytes. Then,
there is the VARHDRSZ (now we're at 20), the flag byte (21), and the
range type oid (25). With alignment (if it's aligned at all), that's
either 28 or 32
On Sat, 2011-01-08 at 20:32 -0500, Robert Haas wrote:
On Sat, Jan 8, 2011 at 4:05 PM, Jeff Davis pg...@j-davis.com wrote:
On Sat, 2011-01-08 at 15:47 -0500, Robert Haas wrote:
On Sat, Jan 8, 2011 at 3:12 PM, Jeff Davis pg...@j-davis.com wrote:
Any ideas? Maybe, with alignment and a flags
On Sat, Jan 8, 2011 at 9:12 PM, Jeff Davis pg...@j-davis.com wrote:
Oh, hmm. What generic functions did you have in mind?
Well, input/output, comparisons, overlaps, intersection, minus, and all
the necessary GiST support functions.
Without generic functions, the only choices we have are:
* Jeff Davis:
On Tue, 2011-01-04 at 14:18 +, Florian Weimer wrote:
* Jeff Davis:
4. For the GiST penalty function, and perhaps some picksplit algorithms,
it might be nice to know the length of a range, or do some other kinds
of math. It introduces a lot of complexity to try to
On Fri, 2011-01-07 at 08:21 +, Florian Weimer wrote:
http://www.postgresql.org/docs/8.4/static/xoper-optimization.html
I'm wondering if one of these hint functions can be reused to compute
range lengths.
Interesting idea.
However, I don't really see a way to make that work. These
On Thu, 2011-01-06 at 09:30 +0900, Hitoshi Harada wrote:
Robert Haas originally began to propose the idea of type
interface to get together three of KNN-GIST, range type and window
frame issue. For KNN-GIST, it was committed by extending pg_amop
without considering others and range type will
On Wed, 2011-01-05 at 12:07 -0800, Jeff Davis wrote:
The current design for range types doesn't ask for add or subtract.
Although it might be interesting to try to use such an interface for
range types, it introduces a lot of complexity and makes it easier to
cause subtle problems (consider
On Thu, Jan 6, 2011 at 12:32 PM, Jeff Davis pg...@j-davis.com wrote:
On Wed, 2011-01-05 at 12:07 -0800, Jeff Davis wrote:
The current design for range types doesn't ask for add or subtract.
Although it might be interesting to try to use such an interface for
range types, it introduces a lot of
On Wed, Jan 5, 2011 at 12:54 AM, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2011-01-04 at 16:45 -0800, Josh Berkus wrote:
On 1/4/11 10:18 AM, Jeff Davis wrote:
The main drawback here is that only a select group of people will be
defining discrete range types at all, because it would require
2011/1/5 Jeff Davis pg...@j-davis.com:
On Tue, 2011-01-04 at 23:04 +0900, Hitoshi Harada wrote:
CREATE TYPE numrange
AS RANGE (SUBTYPE=numeric, SUBTYPE_CMP=numeric_cmp);
I am interested in how you define increment/decrement operation of
range value in discrete types. The window
2011/1/5 Jeff Davis pg...@j-davis.com:
On Tue, 2011-01-04 at 23:04 +0900, Hitoshi Harada wrote:
CREATE TYPE numrange
AS RANGE (SUBTYPE=numeric, SUBTYPE_CMP=numeric_cmp);
I am interested in how you define increment/decrement operation of
range value in discrete types. The window
On Thu, Jan 06, 2011 at 02:25:01AM +0900, Hitoshi Harada wrote:
2011/1/5 Jeff Davis pg...@j-davis.com:
On Tue, 2011-01-04 at 23:04 +0900, Hitoshi Harada wrote:
CREATE TYPE numrange
AS RANGE (SUBTYPE=numeric, SUBTYPE_CMP=numeric_cmp);
I am interested in how you define
On Wed, 2011-01-05 at 10:41 -0800, David Fetter wrote:
On Thu, Jan 06, 2011 at 02:25:01AM +0900, Hitoshi Harada wrote:
For any type to calculate boundary based on RANGE clause in window
functions, we need some type interface mechanism in the core to know
how to add / subtract values to
2011/1/6 Jeff Davis pg...@j-davis.com:
Even if add and subtract were associated with a range type, there's no
way to tell which range type to pick given the window function syntax
(multiple range types could be defined over the same subtype).
I think the interface question should be addressed
2011/1/4 Jeff Davis pg...@j-davis.com:
I have been updating my work in progress here:
http://git.postgresql.org/gitweb?p=users/jdavis/postgres.git;a=log;h=refs/heads/rangetypes
Right now, it's not in a reviewable state, but those interested can
glance through the code.
Quick synopsis (for
* Jeff Davis:
4. For the GiST penalty function, and perhaps some picksplit algorithms,
it might be nice to know the length of a range, or do some other kinds
of math. It introduces a lot of complexity to try to define math
functions for each subtype, and try to make sure they behave sanely.
Jeff Davis pg...@j-davis.com writes:
2. We need to use the subtype's IO functions, but those may not be
immutable. So, rather than create new IO functions for each range type,
I was thinking that I'd use just three (anyrange_i_in, anyrange_s_in,
and anyrange_v_in), and select the right one at
On Tue, Jan 4, 2011 at 2:29 AM, Jeff Davis pg...@j-davis.com wrote:
I liked Robert's suggestion here:
http://archives.postgresql.org/message-id/aanlktiks_x93_k82b4f_ga634wci0oeb9ftrurf28...@mail.gmail.com
which says that the user can just define a canonicalize function that
will take a range
On Tue, 2011-01-04 at 12:21 -0500, Robert Haas wrote:
It doesn't allow for all of the suggested features. In particular, it
would not allow granules to be specified for discrete ranges. But on
balance, it seems like this is the most conceptually simple and I think
it satisfies the primary
On Tue, 2011-01-04 at 14:18 +, Florian Weimer wrote:
* Jeff Davis:
4. For the GiST penalty function, and perhaps some picksplit algorithms,
it might be nice to know the length of a range, or do some other kinds
of math. It introduces a lot of complexity to try to define math
On Tue, 2011-01-04 at 23:04 +0900, Hitoshi Harada wrote:
2011/1/4 Jeff Davis pg...@j-davis.com:
I have been updating my work in progress here:
http://git.postgresql.org/gitweb?p=users/jdavis/postgres.git;a=log;h=refs/heads/rangetypes
Right now, it's not in a reviewable state, but those
On Tue, Jan 4, 2011 at 1:18 PM, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2011-01-04 at 12:21 -0500, Robert Haas wrote:
It doesn't allow for all of the suggested features. In particular, it
would not allow granules to be specified for discrete ranges. But on
balance, it seems like this is
On 1/4/11 10:18 AM, Jeff Davis wrote:
The main drawback here is that only a select group of people will be
defining discrete range types at all, because it would require them to
define a function first. Perhaps that's for the best, because, (as Tom
pointed out) we don't want someone using
On Tue, 2011-01-04 at 16:45 -0800, Josh Berkus wrote:
On 1/4/11 10:18 AM, Jeff Davis wrote:
The main drawback here is that only a select group of people will be
defining discrete range types at all, because it would require them to
define a function first. Perhaps that's for the best,
I have been updating my work in progress here:
http://git.postgresql.org/gitweb?p=users/jdavis/postgres.git;a=log;h=refs/heads/rangetypes
Right now, it's not in a reviewable state, but those interested can
glance through the code.
Quick synopsis (for illustration purposes only; don't expect
40 matches
Mail list logo
