Re: [HACKERS] operator exclusion constraints

this more. 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

Re: [HACKERS] operator exclusion constraints

On Wed, 2009-11-25 at 15:59 -0800, Jeff Davis wrote: My operator-class-fu is insufficient to render judgment on this point. I think the thing to do is look at a bunch of non-built-in opclasses and check for POLA violations. Ok, I'll consider this more. In cases where the operator class

Re: [HACKERS] [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION

is encountered. However, the statement errors immediately, showing that steps 3 and 4 are pipelined. 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

Re: [HACKERS] [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION

On Thu, 2009-11-26 at 00:35 -0500, Andrew Dunstan wrote: On Wed, November 25, 2009 3:56 pm, Jeff Davis wrote: I worry that we're getting further away from the original problem. Let's allow functions to get the bytes of data from a COPY, like the original proposal. I am not sure COPY

Re: [HACKERS] [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION

to generalize this as a data cleanup feature that can handle ragged input. That seems like a separate problem that will distract from the original use case. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION

-- Datum dvalues[] + Row description (look on SRF API) terminate_funnction(fcinfo) Don't you still need the functions to accept an argument of type internal? Otherwise, we lose the ability to copy a buffer to the dblink connection, which was the original motivation. Regards, Jeff Davis

Re: [HACKERS] [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION

, not records. So forcing it to deal with records is inconsistent. 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

Re: [HACKERS] [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION

patch maintains those semantics. 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

Re: [HACKERS] [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION

INTO mytable SELECT * FROM myfunc(); And that already works fine. So what use case are you concerned about? 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

Re: [HACKERS] [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION

or binary: just another format to _represent_ records as a sequence of bytes. A CSV file is not a set of postgresql records until COPY interprets it as such. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION

. If SRFs use a tuplestore in that situation, it sounds like that should be fixed. Why do we need to provide alternate syntax involving COPY? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [HACKERS] operator exclusion constraints

(). I realize there are two tuples, but maybe it makes sense to just call it twice? Are you suggesting I change the error output, or reorganize the code to try to reuse BuildIndexValueDescription, or both? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] New VACUUM FULL

On Mon, 2009-11-16 at 13:37 +0900, Itagaki Takahiro wrote: Jeff Davis pg...@j-davis.com wrote: You left INPLACE in the patch Oops, removed. Sounds fine, but worth a mention in the documentation. Just add to the columns part of the VACUUM page something like: If specified, implies

Re: [HACKERS] New VACUUM FULL

explicitly. In that case it should be set in vacuum() but not in gram.y (unless specified by the user). However, for VACOPT_VACUUM, I think that's still in the territory of gram.y. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] operator exclusion constraints

or an operator exclusion constraint over all three columns. The former took ~ 15 s, the latter ~ 21.5 s. That seems acceptable. Great news. I had similar results, though they depend on the conflict percentage as well (I assume you had zero conflicts). Regards, Jeff Davis -- Sent via pgsql

Re: [HACKERS] operator exclusion constraints

: http://archives.postgresql.org/message-id/1258226849.708.97.ca...@jdavis 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

Re: [HACKERS] operator exclusion constraints

copied similar code for relchecks, see pg_constraint.c:570. If you have a suggestion, I'll make the change. It doesn't sound too urgent though, to me. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] operator exclusion constraints

On Mon, 2009-11-09 at 09:12 -0800, David E. Wheeler wrote: On Nov 8, 2009, at 7:43 PM, Jeff Davis wrote: Either of those names are fine with me, too. The current name is a somewhat shortened version of the name operator-based exclusion constraints, so we can also just use that name

Re: [HACKERS] New VACUUM FULL

syntactical headaches. 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

Re: [HACKERS] New VACUUM FULL

an updated version to the new commitfest entry. 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

Re: [HACKERS] New VACUUM FULL

cleaner to set all of the options properly early on, rather than waiting until vacuum() to interpret the combinations. I haven't looked at the implementation in detail yet, but at a glance, it seems to be a good approach. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] next CommitFest

happened with at least a couple patches that have been assigned to me. Either the code itself is interesting, or the feature is useful enough that I would want to learn about it anyway. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] next CommitFest

the community has always given extra help to first-time contributors. If anyone sees a new contributor being ignored, they should make an effort to help. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] next CommitFest

people from reviewing, but I can understand how it might be more frustrating and less productive for them. An important part of review is to read the relevant mailing list threads and try to tie up loose ends and find a consensus. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list

Re: [HACKERS] next CommitFest

have a hard time imagining it's more than a couple people. Maybe they just need a nice reminder to be a more helpful community member if they want timely feedback on their work? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] operator exclusion constraints

, 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

Re: [HACKERS] operator exclusion constraints

. This is purely a documentation issue, so there are bound to be a few of these things that I can clarify at once. 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

Re: [HACKERS] operator exclusion constraints

of people agree, I'll change it to EXCLUDE. 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

Re: [HACKERS] operator exclusion constraints

as a tie-breaker. I think that EXCLUSION and EXCLUDE are the options still in the running here. 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

Re: [HACKERS] operator exclusion constraints

). EXCLUDING (...) BY ... I think that's better, but still sounds a little wrong to me. 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

Re: [HACKERS] operator exclusion constraints

there aren't perfect, either. 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

Re: [HACKERS] operator exclusion 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

Re: [HACKERS] Proposal - temporal contrib module

periods of time, and that has a very clear meaning with respect to scheduling. 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

Re: [HACKERS] operator exclusion constraints

to find tuples mutually exclusive with the new tuple; and NOT makes that a little less clear, in my opinion. But I'm fine with it if that's what everyone else thinks is best. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] operator exclusion constraints

agreement around EXCLUSION ... CHECK WITH. We should stick with the current syntax unless there's a good consensus around some other specific proposal. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] operator exclusion constraints

). Although the current syntax isn't great, it is declarative, and it does allow a variety of constraints. I certainly welcome ideas that will make a better trade-off here. At the end, I just want a feature that can implement temporal keys. Regards, Jeff Davis -- Sent via pgsql-hackers mailing

Re: [HACKERS] operator exclusion constraints

a specific alternative in mind? How about just WITH? 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

Re: [HACKERS] operator exclusion constraints

clear quite soon if this is going to make it into 8.5. Personally I think the current syntax is pretty good. 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

[HACKERS] proposal: operator exclusion constraints with cardinality

to make sure the semantics can work reasonably well. I haven't implemented the syntax or catalog changes yet, but the basic semantics with a hard-coded cardinality seem to hold up. Thoughts? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] proposal: operator exclusion constraints with cardinality

On Sun, 2009-11-01 at 22:49 -0500, Tom Lane wrote: you should have no hard-wired upper bound on how many of them you allow. You're right. I saw something that looked easy to implement, but in practice it wouldn't be very useful. Regards, Jeff Davis -- Sent via pgsql-hackers mailing

Re: [HACKERS] proposal: operator exclusion constraints with cardinality

, and then use a CHECK constraint to limit that field. The fact that updates follow the chain of concurrent updates makes that work nicely. That doesn't seem to work for general overlapping and unaligned time periods, however. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] Syntax for partitioning

. We could use typmod, I suppose, but even that won't hold a full Oid. Any ideas/suggestions? 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

Re: [HACKERS] Syntax for partitioning

functions, e.g. exprTypmod(). I haven't looked at all of these places yet, so maybe a few simple changes would allow us to treat typmod as a full 32 bits. Or perhaps it could just be expanded to a signed 64-bit int. What do you think? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Syntax for partitioning

and creates some catalog bloat, but I'm not too concerned about it right now. Certainly not enough to rewrite the type system. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [HACKERS] Proposal - temporal contrib module

. 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

Re: [HACKERS] Proposal - temporal contrib module

, 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

Re: [HACKERS] Proposal - temporal contrib module

for this kind of thing. Do you have any ideas or guidance here? 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

Re: [HACKERS] Syntax for partitioning

for representing a partition range. It would make it easier to express and enforce the constraint that no two partition ranges overlap ;) Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

served by an extension. 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

Re: [HACKERS] Scaling up deferred unique checks and the after trigger queue

On Mon, 2009-10-26 at 17:23 +, Dean Rasheed wrote: If it's of any relevance, I'm currently using an optimised build, with assert checking off. [Linux x86_64, 2 core Intel Core2] Ok, I'm able to reproduce it now. Thanks for looking into it! Regards, Jeff Davis -- Sent via pgsql

Re: [HACKERS] Scaling up deferred unique checks and the after trigger queue

with a non-deferrable constraint? I'll keep looking into it. Thanks, 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

Re: [HACKERS] toast.fillfactor is documented but not recognized?

briefly I would assume that it could be set. 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

Re: [HACKERS] Scaling up deferred unique checks and the after trigger queue

checking. Any comments welcome. I'll also take a look at your patch in the next few days. 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

Re: [HACKERS] pre-proposal: type interfaces

wants. That makes sense. Thanks, 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

Re: [HACKERS] B-tree leaf node structure

. However, I'd like to add that there's a feature that never quite made it called Grouped Index Tuples (GIT) that might still be viable: http://community.enterprisedb.com/git/ Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

[HACKERS] pre-proposal: type interfaces

, perhaps something else. 3. Use extra flags in CREATE OPERATOR somehow Thoughts? 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

Re: [HACKERS] Going, going, GUCs!

you're testing. 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

Re: [HACKERS] per table random-page-cost?

% and 50% is only a factor of two. The higher cache hit ratios that are lower than almost 100% seem unlikely: what kind of scenario would involve a stable 90% cache hit ratio for a table? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] per table random-page-cost?

different feature. I'm not clear on the scenario that we're trying to improve. 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

Re: [HACKERS] operator exclusion constraints [was: generalized index constraints]

if that fits nicely with the spec or not. I tried to move the WHERE clause right before or after the index_parameters, but that resulted in shift/reduce conflicts. Thoughts? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] [GENERAL] contrib/plantuner - enable PostgreSQL planner hints

something to apply only to a subquery. I'm still hoping that someone will come up with a more elegant solution to solve that problem though. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] alpha 2 release notes

out all of the alpha releases, they might have forgotten to try some of the features from alpha1. That being said, it's probably a good idea to highlight or mark the features new to alpha2 somehow, perhaps with a *. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql

[HACKERS] missing entry in GucSource_Names

. Regards, Jeff Davis diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c index 1f63e06..776efe3 100644 --- a/src/backend/utils/misc/guc.c +++ b/src/backend/utils/misc/guc.c @@ -460,6 +460,7 @@ const char *const GucSource_Names[] = /* PGC_S_ARGV */ command line

Re: [HACKERS] Re: [GENERAL] contrib/plantuner - enable PostgreSQL planner hints

Raney did that a while back: http://archives.postgresql.org/pgsql-patches/2008-07/msg00011.php He also had an accompanying visual tool to navigate the output in a meaningful way. If he has moved on to other projects, it would be great if someone could pick it up. Regards, Jeff Davis

Re: [HACKERS] transaction_isolation vs. default_transaction_isolation

clear which setting overrides the other. 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

Re: [HACKERS] Issues for named/mixed function notation patch

for which parameters. 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

Re: [HACKERS] Writeable CTEs and side effects

if this is a problem, but it seems like we're essentially allowing a complex transaction to take place in one statement. Is that what we want? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [HACKERS] Writeable CTEs and side effects

, 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

Re: [HACKERS] Writeable CTEs and side effects

obvious how many times the subquery should be executed, and it might change based on the plan. We could make the same rules for a subquery that has side effects, and always materialize it. But for now maybe CTEs are a better place to get the feature working. Regards, Jeff Davis -- Sent via

Re: [HACKERS] Issues for named/mixed function notation patch

it, assuming there's a reasonable way to implement it, and assuming that the VARIADIC keyword is required. 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

Re: [HACKERS] Issues for named/mixed function notation patch

/pgsql-hackers/2009-09/msg01792.php Do you think it would be reasonable to implement? 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

Re: [HACKERS] Issues for named/mixed function notation patch

to guard us better against future changes, which seemed like a concern before. I don't have a strong opinion or a specific problem with making VARIADIC optional, so it's OK with me. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] Issues for named/mixed function notation 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

Re: [HACKERS] COPY enhancements

, Jeff Davis *** /home/jdavis/wd/git/postgresql/src/test/regress/expected/copy_errorlogging.out 2009-10-04 10:24:15.0 -0700 --- /home/jdavis/wd/git/postgresql/src/test/regress/results/copy_errorlogging.out 2009-10-04 10:24:32.0 -0700 *** *** 46,58 -- both

Re: [HACKERS] Issues for named/mixed function notation patch

Brendan and my patches and combine them with your patch. Regards, Jeff Davis diff --git a/doc/src/sgml/syntax.sgml b/doc/src/sgml/syntax.sgml index 50c4128..542646d 100644 --- a/doc/src/sgml/syntax.sgml +++ b/doc/src/sgml/syntax.sgml @@ -1505,6 +1505,10 @@ sqrt(2) The list of built

Re: [HACKERS] Issues for named/mixed function notation patch

On Fri, 2009-10-02 at 16:06 +0200, Pavel Stehule wrote: see attachment, please Thank you, marked as ready for committer. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

Re: [HACKERS] Issues for named/mixed function notation 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

Re: [HACKERS] Issues for named/mixed function notation patch

? Also, you should consistently pass NIL when you mean an empty list, but sometimes you pass NULL to FuncnameGetCandidates(). Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

Re: [HACKERS] Issues for named/mixed function notation patch

On Mon, 2009-09-28 at 19:26 +0200, Pavel Stehule wrote: Also, you should consistently pass NIL when you mean an empty list, but sometimes you pass NULL to FuncnameGetCandidates(). It's bug, where is it? In regproc.c. Jeff -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Rejecting weak passwords

the hash function. That doesn't solve the problem of an administrator brute-forcing your password. 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

Re: [HACKERS] operator exclusion constraints

at the beginning of this commitfest that required some substantial language changes. I did find this commitfest extremely productive for my feature. Right now I'm trying to provide some useful feedback to Paval for his patch. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] operator exclusion constraints

in particular, so I'm more than willing to set my minor frustrations aside as long as that continues. 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

Re: [HACKERS] Issues for named/mixed function notation patch

positional notation instead. What is the intended behavior? I think we should always require VARIADIC to be specified regardless of using named notation. I'm still reviewing the code. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] operator exclusion constraints [was: generalized index constraints]

, that conflicts with the word USING. We can either eliminate the USING variant from opt_class (unless it's necessary for some reason or I missed it in the documentation), or we can use another word (e.g. WITH or WITH OPERATOR) if you don't like CHECK. Regards, Jeff Davis -- Sent via pgsql

Re: [HACKERS] Join optimization for inheritance tables

at the actual patch yet. 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

Re: [HACKERS] WIP: generalized index 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

Re: [HACKERS] operator exclusion constraints [was: generalized index constraints]

for the syntax because it appears to be the path of least resistance. 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

Re: [HACKERS] WIP: generalized index constraints

, 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

Re: [HACKERS] operator exclusion constraints [was: generalized index constraints]

case you described above. If we move away from multiple constraints per index, are you suggesting that I also move the constraints out of pg_constraint and back into pg_index? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] WIP: generalized index constraints

as implementation goes, I think there would be very little choice but to use the insert-the-index-entry-first, check-later approach; so your ideas involving extra state in shared memory seem to fall to the ground anyhow. True. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] operator exclusion constraints [was: generalized index constraints]

, should I explicitly disallow multiple constraints on one index then? 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

Re: [HACKERS] operator exclusion constraints [was: generalized index constraints]

, but I don't see any major problems. So, should I eliminate the latter syntax and only support the former, or should I support both? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [HACKERS] operator exclusion constraints [was: generalized index constraints]

it because it connects back to the name operator exclusion constraint. Regards, Jeff Davis --- Results (oversimplified benchmark): As a control, two unique btrees (using old uniqueness mechanism) takes 37s. DDL (old syntax, haven't changed it yet): create table one

[HACKERS] operator exclusion constraints [was: generalized index constraints]

to fix that now. I'd like some more input before I actually take care of this item. The rest of the issues were mostly non-controversial. I will start making some of these changes and post an updated patch and TODO list. Regards, Jeff Davis [1] http://archives.postgresql.org/pgsql

Re: [HACKERS] operator exclusion constraints [was: generalized index constraints]

On Sun, 2009-09-20 at 17:54 -0400, Tom Lane wrote: Jeff Davis pg...@j-davis.com writes: 1. Constraint syntax, part of CREATE/ALTER TABLE: [CONSTRAINT name] EXCLUSION (expr OPERATOR op, ...) Have you actually built this grammar? I don't think it avoids the problem, because OPERATOR

Re: [HACKERS] operator exclusion constraints [was: generalized index constraints]

appear to compile and recognize the grammar with EXCLUSION as an unreserved keyword. I'm in the middle of changing a lot of things around, so I can't say that it works beyond that. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] WIP: generalized index constraints

] Does that make sense? Does someone have a better idea? Am I missing other issues here? How do I test if two functions/expressions: a. are identical? b. have matching signatures? Regards, Jeff Davis *: Understandably, there is no strategy for for most data types. However, if your

Re: [HACKERS] WIP: generalized index constraints

, perhaps I should just test for equal expressions? 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

Re: [HACKERS] WIP: generalized index constraints

ALTER TABLE, I need to know soon. Regards, Jeff Davis [1] http://archives.postgresql.org/pgsql-hackers/2008-06/msg00404.php [2] http://archives.postgresql.org/pgsql-hackers/2009-07/msg00302.php [3] http://archives.postgresql.org/pgsql-hackers/2009-07/msg00406.php -- Sent via pgsql

[HACKERS] operator exclusion constraints [was: generalized index constraints]

On Sat, 2009-09-19 at 10:48 -0700, Jeff Davis wrote: CONSTRAINT foo_constr (a op, ...) { USING INDEX foo_idx | USING method } I am updating the syntax to be: CONSTRAINT foo_constr EXCLUSION (a op, ...) { USING method | INDEX foo_idx }; First, I think EXCLUSION makes a perfect noun

<    6   7   8   9   10   11   12   13   14   15   >