example you give, with triggers
disabled, it's not safe to allow the user to execute arbitrary
operations.
In other words, if you wrap an unprivileged operation inside of
privileged operations, it seems like the unprivileged operation then
becomes privileged. Right?
Regards,
Jeff
her
terminated or is idle? That might be confusing.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
le or
database."
I think some kind of hidden GUC might be the best option. I tend to
agree that a third option to the "autovacuum" setting would be
confusing.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Tue, 2011-03-29 at 21:43 -0300, Alvaro Herrera wrote:
> I think it would be better to have
> some sort of option to disable autovacuum completely which would be used
> only during pg_upgrade.
Sounds reasonable to me.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mai
On Tue, 2011-03-29 at 15:52 -0400, Bruce Momjian wrote:
> Does anyone have any other suggestions on how to make sure autovacuum
> does not run in freeze mode?
Can you run in single user mode?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
On Fri, 2011-03-18 at 10:27 -0400, Robert Haas wrote:
> ERRCODE_(WARNING_?)REPLICATION_WAIT_CANCELLED
>
> ...which might have something to recommend it.
Works for me.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
On Fri, 2011-03-18 at 08:27 -0400, Robert Haas wrote:
> On Thu, Mar 17, 2011 at 6:00 PM, Jeff Davis wrote:
> > On Wed, 2011-03-16 at 13:35 -0400, Robert Haas wrote:
> >> 2. If a query cancel interrupt is received (pg_cancel_backend or ^C),
> >> then cancel the sync r
errcode(). It seems like it should -- this is the kind of thing that the
client is likely to care about, and may want to handle specially.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresq
postgresql.org/pgsql-hackers/2008-10/msg01279.php
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e, I'd prefer #1 to #2. I think #2 is a bad path to take, and
we'll end up with a lot of unintuitive and error-prone operators.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, 2011-03-05 at 18:33 -0500, Bruce Momjian wrote:
> I am seeing the following compile problem with gmake -j2:
>
For what it's worth, I'm still seeing this problem too:
http://archives.postgresql.org/pgsql-hackers/2010-12/msg00123.php
I can reproduce it every time.
Regar
ons off and was poking around, especially at
> MemoryContextStats(TopMemoryContext), but was not rewarded.
Where is all of that memory going during recovery? Recovery shouldn't
use much memory at all, as far as I can tell.
What's even allocating memory at all?
Regards,
Jeff
s the difference between failover and switchover, right? At
least Slony makes such a distinction, as well.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t for the next commitfest to be included in
core? That would allow range types and exclusion constraints to be used
out-of-the-box in 9.2.
Only if you think it's reasonable to put it in core, of course. If
extensions are easy enough to install, maybe that's not really
necessary.
Regard
On Fri, 2011-02-11 at 15:14 -0500, Robert Haas wrote:
> On Fri, Feb 11, 2011 at 3:03 PM, Jeff Davis wrote:
> > Well, there is a certain amount of localized clarity, I will agree with
> > that. The complexity comes when you accidentally rely on some
> > transformation which
LL boundaries were likely to be confusing
and served no obvious use case not handled by infinity).
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
or those two to be equivalent.
And that would be a runtime error, caught during testing only if you're
lucky.
Now, I agree that lack of closure on UNION exhibits many of the problems
that I am pointing out related to forbidding empty ranges. However, I'm
not sure if that means we should gi
On Fri, 2011-02-11 at 13:50 -0500, Robert Haas wrote:
> On Fri, Feb 11, 2011 at 1:11 PM, Jeff Davis wrote:
> > Similarly, "intersection" of ranges is somewhat analogous to
> > multiplication of numbers.
>
> I had a feeling that we might be going in this direct
current value" to
me.
Sequences have other useful operations, like "next", and things like
"overlaps" don't really seem to make sense (at least not in a practical
way that I can tell).
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
; "allow_empty_ranges".
I think that would be the least desirable option. If we don't like empty
ranges, let's prohibit them entirely.
Or, there are always check constraints...
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
hould probably not be used in a context
where empty ranges are permitted (if they are, it's likely a mistake and
an error should be thrown).
My feeling is that we should let the operation proceed as far as it is
well-defined, and no further; and I think that means empty ranges should
be allow
t;" means "strictly right of"
"<<" means "strictly left of"
"-|-" means "adjacent" (touching but not overlapping)
I'm open to suggestion about how those behave with empty ranges.
Regards,
Jeff Davis
--
Sen
On Fri, 2011-02-11 at 15:09 +0100, Erik Rijkers wrote:
> On Wed, February 9, 2011 09:35, Jeff Davis wrote:
> > Updated patch.
> >
>
> The operators << >> and -|- have the following behavior with empty ranges:
>
> testdb=# select '-'::i
hings
like:
RANGE[10,20)
But I have a feeling that will either cause a bizarre problem with the
grammar, or someone will think it's not very SQL-like.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, 2011-02-10 at 09:46 -0500, Robert Haas wrote:
> On Tue, Feb 8, 2011 at 7:58 PM, Jeff Davis wrote:
> > On the flip side, if we don't provide review to WIP patches during the
> > 3rd commitfest, how do we expect to get anything close to committable on
> > the
existing test data it will need to be
reloaded to work with the latest.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, 2011-02-10 at 12:04 -0500, Tom Lane wrote:
> "Erik Rijkers" writes:
> > On Wed, February 9, 2011 09:35, Jeff Davis wrote:
> >> Updated patch.
>
> > I just wanted to mention that this latest patch doesn't quite apply as-is,
> > because o
On Wed, 2011-02-09 at 18:07 -0500, Chris Browne wrote:
> rangetest@localhost-> create index i2 on some_data (range(whensit));
> CREATE INDEX
If you make this a GiST index, it should work.
The rewrites so that it can use a btree are an interesting idea though.
Regards,
J
es. The index is a btree index on a normal column, so range types can't
exactly help with that directly -- except maybe as a rewrite like you
say.
One thing you might try is a functional index on (range(whensit)) and
then do: where '...' @> range(whensit).
Does that work for you?
R
RANGE JOIN might have a chance for 9.2 as well. Or, maybe some
other features might find it useful, like partitioning or audit logs.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.o
just posted about
* SQL length function --immutable/stable/volatile?
As always, my repo is here:
http://git.postgresql.org/gitweb?p=users/jdavis/postgres.git;a=log;h=refs/heads/rangetypes
Regards,
Jeff Davis
rangetypes-20110208.patch.gz
Description: GNU Zip compressed data
--
Sent
forward through the attributes.
So, I'll implement this approach. 22 bytes represents 37.5% overhead
above the good ol' PERIOD data type (a lean 16 bytes), but we can make
up some of that if using unbounded ranges. For instance, a half-open
range like "[5, INF)" would only tak
On Wed, 2011-02-09 at 15:39 +0900, Itagaki Takahiro wrote:
> On Wed, Feb 9, 2011 at 14:50, Jeff Davis wrote:
> > 1.
> > The obvious constructor would be:
> > range(1, 10)
> > But is that [1, 10), (1, 10], (1, 10), or [1, 10]? We need to support
> > all 4, an
is used to mean
> "inclusive".'
Thank you, fixed.
> And btw: it should mention here that the range*inf* functions,
> an underscore to separate 'range' from the rest of the function name, e.g.:
>range_linfi_() => infinite lower bound, inclusi
ge operand (which is actually stored with the range).
But that fix won't work for the constructors above, because there is no
range argument to start from.
So: in what contexts are functions called that get_fn_expr_argtype()
might fail; and are the above constructors at risk for that?
On Tue, 2011-02-08 at 09:10 -0800, Jeff Davis wrote:
> On Mon, 2011-02-07 at 18:23 +0100, Dimitri Fontaine wrote:
> > I would think
> >
> > CREATE TYPE foo AS RANGE (bar) USING (btree_ops);
> >
> > The USING clause is optional, because you generally have a
ew to WIP patches during the
3rd commitfest, how do we expect to get anything close to committable on
the 1st commitfest of the next cycle?
> Although it doesn't
> feel like it at the moment, we have actually made great strides in
> absorbing large patches.
I agree completely.
Regar
en half that size.
My concern is that, aside from code, my patch didn't make much progress
this commitfest. And the code progress was mostly me working through my
own TODO list on things like GiST support -- which didn't represent any
real decisions, it was mostly just a matter of co
> that this patch is more than ready for beta.
I appreciate the sentiment, but in addition to some cleanup, any patch
like this at least requires some discussion. It's a language change
we'll be supporting for a long time.
At minimum, we're a couple hundred emails shy of a real co
grammar, functionality,
etc. Without some checkpoint, the chances that everyone agrees with all
of these decisions at the beginning of the next commitfest is zero.
Is the commitfest not the right place to do this? If not, then when?
Regards,
Jeff Davis
--
Sent via pgsql-hackers
CANONICAL", so where do those fit?
If CREATE TYPE already has an options list, it seems a little strange to
add grammar to support this feature. "USING" doesn't seem to mean a lot,
except that we happen to use it in other contexts to mean "operator
class".
Regards,
the array type. I don't think we want to do something similar
for range types -- especially if there are alternative range types for a
given base type.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
htt
On Mon, 2011-02-07 at 13:33 +0100, Dimitri Fontaine wrote:
> Hi,
>
> Jeff Davis writes:
> > * Should pg_range reference the btree opclass or the compare function
> > directly?
>
> I would say yes. We use the btree opclass in other similar situations.
Ok, but w
I'll look into it a little more, but an updated
patch should come soon.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=7841a22648c3f4ae46f674d7cf4a7c2673cf9ed2
What does PredicateLockTuple do that needs a share lock? Does a pin
suffice?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
nclude btree_gist in
core, to make range types more useful with exclusion constraints
out-of-the-box. This should be left for later, I'm just including this
for the archives so it doesn't get lost.
Regards,
Jeff Davis
rangetypes-20110205.patch.gz
Description: GNU Zip compres
On Sun, 2011-01-30 at 17:14 -0500, Tom Lane wrote:
> Jeff Davis writes:
> > On Sun, 2011-01-30 at 02:55 +, Thom Brown wrote:
> >> postgres=# select '[18,20]'::numrange @> 19;
> >> ERROR: operator does not exist: numrange @> integer
&g
totally clear whether elog is right here, but it seems to me a
> conceptually similar case to some I found elsewhere that elog was
> used.
Looks good. It also looks like it contains a bugfix for subtransactions,
right?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing lis
sonable? None of that is really
> *necessary*, but it seemed cleaner and clearer that way once I
> looked at the code with the changes you suggested.
Yes, I like those changes.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
in my free time to
complete a thorough review. If you have other patches to review/commit
then I will still be making progress reviewing SSI.
However, I would recommend leaving yourself some time to think on this
one if you don't already understand the design well.
Regards,
Jeff Da
een set?
I think that's a safe assumption. If there is some kind of noticeable
difference in conflict rates or runtime, that probably indicates a bug
in the new or old code.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to y
he OldestXmin value on the call to HTSV?
I believe RecentGlobalXmin should work.
And I don't think the original switch statement I posted did the right
thing for HEAPTUPLE_LIVE. I think that case needs to account for the
visible flag (if it's live but not visible, that's the same
On Mon, 2011-01-31 at 13:55 -0600, Kevin Grittner wrote:
> Jeff Davis wrote:
>
> > I don't think this function really cares about the visibility with
> > respect to the current snapshot, right?
>
> What it cares about is whether some other particular top leve
explain
would be helpful.
As an example, consider that Robert Haas recently suggested using an
infomask bit to mean frozen, rather than actually removing the xid, to
save the xid as forensic information. If that were to happen, your code
would be reading an xid that may have been re-used.
Regards,
le byte. Read only transactions have nothing to do with the
> traffic under either alternative.
Ok, great. When I read that before I thought that WAL might need to be
sent for implicit RO transactions. I will read it more carefully again.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
a plan, but there is also some resistance to it:
http://archives.postgresql.org/message-id/23698.1295566...@sss.pgh.pa.us
We don't need a perfect solution for 9.1, but it would be nice if we had
a viable plan for 9.2.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hacker
le?
* representation or alignment issues
* parser should be improved to handle spaces and quoting better
* Should btree_gist be pulled into core to make it easier to use
exclusion constraints with range types?
* Typmod (optional)
Regards,
Jeff Davis
rangetypes-20110130.pat
nt4.
select '[18,20]'::numrange @> 19.0;
works.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, 2011-01-29 at 14:42 -0500, Tom Lane wrote:
> Jeff Davis writes:
> > On Fri, 2011-01-28 at 21:52 +, Thom Brown wrote:
> > Also, if I try the same, but with a different name for the type, I get
> > the same error. Why does that restriction exist? Can't you h
at
tuple. It also makes sense for arrays.
But ranges are arbitrarily long, and don't have any defined "step", so
that means an infinite number of keys. GiST works better for that.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
bigint sure seems like a
> good idea.
OK, I'll change intrange to int4range, and add int8range. int2range
doesn't seem useful, though.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
would you extract from the value '[1.23,4.56)' ?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I shouldn't have been able to create this type in the
> first place?
The types are in two different schemas. It's just as though you created
a table called pg_class.
To drop the one you created, do:
DROP TYPE public.numrange;
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ifficult part is defining the "canonical" function if
it is applicable, and the "subtype_float" function which is necessary
for GiST.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, 2011-01-25 at 15:22 -0600, Kevin Grittner wrote:
> Jeff Davis wrote:
>
> > I think just annotating RWConflict.in/outLink and
> > PredTranList.available/activeList with the types of things they
> > hold would be a help.
> >
> > Also, you say some
pmod support (optional)
This is nearing completion. GiST is by far the most amount of effort
remaining that I'm aware of. Comments about the API, naming,
representation, interface, funcationality, grammar, etc. are welcome.
Regards,
Jeff Davis
rangetypes-20110127.patch.gz
Description
r a real cycle, which would let T1
succeed?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
's OK to leave it to 9.2. But if it's a RO deferrable transaction,
it's just going to go to sleep in that case anyway; so why not look for
an opportunity to get a safe snapshot right away?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
I'll address the rest of your comments in a later email.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
gh memory to
hold a transaction for each connection, plus max_prepared_xacts, plus
one, I think that's true. But maybe that could be made more clear?
I'll keep working on this patch. I hope I can be of some help getting
this committed, because I'm looking forward to this feature. And I
be fairly easy to explain to users. If there is a visibility
lag, then we just say "finish the write transactions, and progress will
be made". And if the system is idle, they should see identical data.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
On Fri, 2011-01-21 at 12:31 -0500, Robert Haas wrote:
> On Thu, Jan 20, 2011 at 4:29 AM, Jeff Davis wrote:
> > New patch. I added a lot of generic range functions, and a lot of
> > operators.
> >
> > There is still more work to do, this is just an updated patch. The
&g
,
Jeff Davis
rangetypes-20110119.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
s the compatibility GUC to turn "serializable"
into "repeatable read".
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
range boundaries for the first cut, and leave room in the
representation so that it can be added when there is a more thorough
proposal for NULL range boundaries?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
or perhaps I'm
over-thinking the null semantics.
3. perhaps fix typmod
4. documentation
5. more tests
7. better parser
Regards,
Jeff Davis
rangetypes-20110114.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
linux has actually changed the heuristic:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a63d83f427fbce97a6cea0db2e64b0eb8435cd10
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
eful.
> > * If it's a fixed-length type, we can save the varlena header byte on
> > the overall range; but we lose the ability to save space when one of the
> > boundaries of the range is missing (NULL or INF), and it would
> > complicate the code a little. Thought
.25389.6.ca...@jdavis-ux.asterdata.local
It's gotten much worse recently, where changing a c file seems to
require multiple top-level "make install" commands to take effect (as
Tom describes). I don't think it's limited to the access/ subdirectory,
though.
Regards,
Jeff Davis
of your backup ;) ).
If you think you are restoring a backup, and it's really a primary that
crashed, then you run into one of the two problems that I mentioned
(which are less severe than corruption, but very annoying).
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pg
think that the simplicity of
unrestricted file copy is worth these problems?
We could probably make some fairly minor changes, like making a file on
the primary and telling users to exclude it from any base backup. The
danger, of course, is that they do copy it, and their backup is
compromised.
Re
of extra work during recovery; and
2. In the same situation, if the WAL referenced in the backup_label
does not exist, then it PANICs with a HINT to tell you to remove the
backup_label.
Is this an opportunity to solve these problems and simplify the code?
Regards,
Jeff Davis
--
hy users
wouldn't value the combination of 2PC and NOTIFY.
I don't expect this to be a huge roadblock for the feature though. It
seems fairly contained. I haven't read the 2PC code either, but I don't
expect that you'll need to change the rest of your algorithm just to
support i
If it's a fixed-length type, we can save the varlena header byte on
the overall range; but we lose the ability to save space when one of the
boundaries of the range is missing (NULL or INF), and it would
complicate the code a little. Thoughts?
Regards,
Jeff Davis
rangetypes-20110110.p
Right, that's what I'm worried about.
If we must have a GUC, perhaps we could publish a sunset one release in
the future.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
So, why was it eliminated? If the type output function got the type OID,
would it be enough to use fn_expr_get_argtype() for the other generic
functions?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
On Sat, 2011-01-08 at 20:32 -0500, Robert Haas wrote:
> On Sat, Jan 8, 2011 at 4:05 PM, 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 wrote:
> >> > Any ideas? Maybe, with alignme
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 wrote:
> > > Any ideas? Maybe, with alignment and a "flags" byte (to hold
> > > inclusivity, infinite
On Sat, 2011-01-08 at 15:47 -0500, Robert Haas wrote:
> On Sat, Jan 8, 2011 at 3:12 PM, Jeff Davis wrote:
> > Any ideas? Maybe, with alignment and a "flags" byte (to hold
> > inclusivity, infinite boundaries, etc.), the extra 4 bytes doesn't cost
> > much, any
ment and a "flags" byte (to hold
inclusivity, infinite boundaries, etc.), the extra 4 bytes doesn't cost
much, anyway?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
way to make that work. These functions are
tied to the operator, so it would be awkward to try to connect it to the
GiST support functions. Also, it doesn't seem to be an exact fit,
because the RESTRICT function is used to compute the selectivity as of
right now using current statistics.
Regar
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
> caus
d range type will be as well. Not getting
> them together might be the answer.
We may end up combining all of these concepts into type interfaces
later. Now that we have multiple potential users of type interfaces, it
will be easier to design type interfaces to work well for all of them.
Regard
ned over the same subtype).
I think the interface question should be addressed more directly with a
"type interfaces" patch.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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. Perhap
On Tue, 2011-01-04 at 23:04 +0900, Hitoshi Harada wrote:
> 2011/1/4 Jeff Davis :
> > 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'
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 complexi
e serialized form right after serialization */
range = canonical(range)
I would lean toward the latter because it's simpler on the user (and
allows non-C functions). But perhaps an efficiency argument could be
made for the former because it could avoid one round of
deserialize/reserialize
impler designs. Conceptually, defining new
ranges of different granularity with ease sounds like a great idea --
but it introduces a lot of complexity (and generated a lot of different
opinions), so it was not included in this design. Similarly, I am
leaning away from lots of user-specified options un
folks that might want to
rebase or translate some old notes.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
701 - 800 of 1617 matches
Mail list logo
