Re: [HACKERS] Index Tuple Compression Approach?

could effectively do both. The bigger difference that I see is that GIT doesn't just group together ranges of keys, it also groups by heap page number (or a small range of page numbers, as Simon pointed out). Regards, Jeff Davis ---(end of broadcast

Re: [HACKERS] Another idea for index-only scans

tables. However, it also sounds a little dangerous. If you test your application performance, but not thoroughly enough, you might end up with a surprise when going into production. Regards, Jeff Davis ---(end of broadcast)--- TIP 3: Have you

Re: [HACKERS] invalid data for encoding

consider, and we should consider them carefully. However, I don't think that the current behavior is correct, for the same reason that I don't think that February 31st, 2007 should be allowed in a date column. Regards, Jeff Davis ---(end of broadcast

Re: [HACKERS] Per-function search_path = per-function GUC settings

in a transaction block. However, we already have a similar situation with creating a security definer function and then revoking access, so maybe it's already expected. I don't have a strong opinion, I just wanted to bring that up. Regards, Jeff Davis ---(end

Re: [HACKERS] Per-function search_path = per-function GUC settings

, Jeff Davis ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

Re: [HACKERS] Per-function search_path = per-function GUC settings

search_path=foo; | cat module_install.sql | psql my_db ..or $ psql my_db = SET search_path=foo; = \i module_install.sql Regards, Jeff Davis ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Per-function search_path = per-function GUC settings

FUNCTION page has a section titled Writing SECURITY DEFINER Functions Safely, so I think it's useful to have it there, too. Regards, Jeff Davis ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http

Re: [HACKERS] [FEATURE REQUEST] Streaming Onlinebackup (Maybe OFFTOPIC)

a lot of the benefit by just having a utility that could discard useless contents that are left over from a previously-recycled file, and then could just reconstruct it later with zeros. Regards, Jeff Davis ---(end of broadcast)--- TIP 5: don't

Re: [HACKERS] [FEATURE REQUEST] Streaming Onlinebackup (Maybe OFFTOPIC)

On Thu, 2007-09-06 at 19:23 -0400, Tom Lane wrote: Jeff Davis [EMAIL PROTECTED] writes: On Thu, 2007-09-06 at 12:08 +0100, Heikki Linnakangas wrote: With file-based log shipping, you can get down to 1 second, by using the archive_timeout setting. It will produce a lot of log files with very

Re: [HACKERS] invalidly encoded strings

' (backslash) somewhere in the string. However, I have no doubt that there are people who use the first strategy anyway, and the proposed change would break that for them. There may be more issues, too. Regards, Jeff Davis ---(end of broadcast

Re: [HACKERS] invalidly encoded strings

On Sun, 2007-09-09 at 17:09 -0400, Tom Lane wrote: Jeff Davis [EMAIL PROTECTED] writes: Currently, you can pass a bytea literal as either: E'\377\377\377' or E'\\377\\377\\377'. The first strategy (single backslash) is not correct, because if you do E'\377\000\377', the embedded null

Re: [HACKERS] invalidly encoded strings

-cosmetic patches for 8.3. Given that database_encoding is frozen for any one DB at the moment, and that that is unlikely to change in the near future, insisting on a solution that allows it to vary is probably unreasonable at this stage of the game. Sounds reasonable to me. Regards, Jeff

Re: [HACKERS] invalidly encoded strings

. If it's done in the scanner it should still accept things like: E'\\377\\000\\377'::bytea right? I think the concern is when they use only one slash, like: E'\377\000\377'::bytea which, as I mentioned before, is not correct anyway. Regards, Jeff Davis ---(end

Re: [HACKERS] invalidly encoded strings

characters are in random order in UTF-8, while Kanji characters are reasonably ordered in EUC_JP. Isn't the collation a locale issue, not an encoding issue? Is there a ja_JP.UTF-8 that defines the proper order? Regards, Jeff Davis ---(end of broadcast

Re: [HACKERS] invalidly encoded strings

, Jeff Davis ---(end of broadcast)--- TIP 6: explain analyze is your friend

Re: [HACKERS] invalidly encoded strings

: invalid byte sequence for encoding UTF8: 0xbd Regards, Jeff Davis test= select version(); version -- PostgreSQL

Re: [HACKERS] invalidly encoded strings

database? If we make convert() operate on bytea and return bytea, as Tom suggested, would that solve your use case? Regards, Jeff Davis ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http

Re: [HACKERS] invalidly encoded strings

or POSIX during initdb, thus disabling any real locale awareness. Regards, Jeff Davis ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes

Re: [HACKERS] invalidly encoded strings

On Tue, 2007-09-11 at 14:48 -0400, Tom Lane wrote: Jeff Davis [EMAIL PROTECTED] writes: On Mon, 2007-09-10 at 23:20 -0400, Tom Lane wrote: It might work the way you are expecting if the database uses SQL_ASCII encoding and C locale --- and I'd be fine with allowing convert() only when

Re: [HACKERS] pg_ctl -w vs unix_socket_directory

the inconsistency between server port number and socket directory is less than ideal. However, I also don't feel very strongly about it. It's rare, and a there are plenty of workarounds. Regards, Jeff Davis ---(end of broadcast)--- TIP 5: don't

Re: [HACKERS] pg_dump vs PQescapeBytea

?). It's a pretty minor issue, but a little inconsistent. Is it worth addressing? 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] Prefix support for synonym dictionary

small. I'd hate to hold it up over such a minor issue, and it seems like a useful feature. If Oleg is unavailable, would you mind just having a second review of the patch to see if they agree with my suggestions, and then mark ready for committer review? Regards, Jeff Davis -- Sent via

Re: [HACKERS] Prefix support for synonym dictionary

are pointing at each others' patches. 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 for 8.5, transformationHook

alternative to XML. It's worthwhile to think about how we can fit our special cases into general APIs -- particularly when we have two similar special cases like JSON and XML. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Patch for 8.5, transformationHook

On Mon, 2009-04-20 at 18:53 +0200, Pavel Stehule wrote: b) it allows constructors for data types (ANSI SQL) datatype(typefield1[, typefiedl2[, typefiedl3[, ...]]]) returns type Can you describe this case in more detail? What section of SQL are you referring to? Regards, Jeff Davis

Re: [HACKERS] Patch for 8.5, transformationHook

for those features, that might indicate a problem. Considering that the next commitfest is only about a month away, I don't think that it is too much of a burden to wait. I didn't have time to do a complete review, so I can't provide much better direction than this right now. Regards, Jeff

[HACKERS] freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )

for opportunities to set hint bits or freeze tuples. 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] freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )

could make a range such that we avoid writing multiple times. And people who don't care about forensic evidence can set it to 0-100M. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [PERFORM] Re: [HACKERS] freezing tuples ( was: Why is vacuum_freeze_min_age100m? )

tuples with different xmins on the same page, some might be older than 100M, which you freeze, and then you will have to come back later to freeze the rest. As far as I can tell, the maximum number of writes is the number of tuples that fit on the page. Regards, Jeff Davis -- Sent via

Re: [HACKERS] freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )

. Everybody *thinks* they don't care about forensic evidence. Until they need it. We already allow setting vacuum_freeze_min_age to zero, so I don't see a solution here other than documentation. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )

of the advantage would be had just by saying that we opportunistically freeze tuples older than 50% of vacuum_freeze_min_age. Regards, Jeff Davis *: As an aside, these GUCs already have incredibly confusing names, and an extra variable would increase the confusion. For instance, they seem

Re: [HACKERS] freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )

of different tuples on the same page. 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] freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )

no distinction between min and max in those two names. I've complained about this before: http://archives.postgresql.org/pgsql-hackers/2008-12/msg01731.php I think both are essentially thresholds, so giving them two names with opposite meaning is misleading. Regards, Jeff Davis -- Sent via pgsql

Re: [HACKERS] freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )

obsolete because now the freezing will normally happen between vacuum_freeze_min_age and vacuum_freeze_table_age; but at least I should be able to remember which of the other parameters is min and which one is max. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers

[HACKERS] opportunistic tuple freezing

transaction ID information for diagnosing problems. Regards, Jeff Davis diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 2034fdc..1d71abf 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -4060,6 +4060,27 @@ COPY postgres_log FROM '/full/path

Re: [HACKERS] opportunistic tuple freezing

. Additionally, the second scan needs to avoid all of the side effects (like double-counting), which might mean some ugly branching. For instance, the big switch statement is completely unnecessary during the second scan. I'll come up with a refactored version of the patch. Regards, Jeff

Re: [HACKERS] opportunistic tuple freezing

to zero), and assorted dml is likely to mean that there are still non-freezable xids on the page (meaning that we still need to write it again, anyway). Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] WIP: generalized index constraints

constraint (in particular, when bootstrapping). Comments, suggestions, ideas? 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] CommitFest 2009-07: Remaining Patches Moved To CommitFest 2009-09

that was directly due to his management efforts. I agree 100%, thanks Robert! 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] Another try at reducing repeated detoast work for PostGIS

that two similar plans for the same query might perform differently due to repeated de-toasting? 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] Another try at reducing repeated detoast work for PostGIS

in explain output), and thus a potential performance problem might catch someone by surprise. I don't see how that could happen with this particular patch, but I thought I would bring it up in case someone else does. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (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] WIP: generalized index constraints

a little strange to me, but that's the current behavior for unique indexes. 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

an ERROR (or at least a WARNING). There is not much of a problem with backwards compatibility. LIKE is shorthand (not stored in catalogs), so it doesn't affect pg_dump/restore. And hopefully there aren't a lot of apps out there creating tables dynamically using the LIKE syntax. Regards, Jeff

Re: [HACKERS] COALESCE and NULLIF semantics

the standard? To make that interpretation work I think you would need to say that ROW(NULL,NULL) _is_ the null value, and you would have to allow things like: select 1 + row(null,null); which seems strange to me. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] COALESCE and NULLIF semantics

apparently each null does have a specific type. It seems to me like the spec would have something to say about ROW(NULL,NULL) versus NULL. Do other systems make a distinction? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] opportunistic tuple freezing

focusing on my other work, so I don't know if this one is going to be in shape for the September commitfest. If someone is interested in doing some performance testing for this patch, let me know. I still think it has potential. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list

Re: [HACKERS] WIP: generalized index constraints

think either of these things are a huge amount of work; they are mostly just decisions that need to be made. I'll start off implementing whatever is easiest/cleanest, and we'll continue the discussion. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Feature Request: JSON input for hstore

, libpq, or the backend? Thoughts? What's wrong with just using a variant of the type input function? With a parameterized insert, it doesn't seem like it's really placing much of a burden on the application. Or am I missing the use case? Regards, Jeff Davis -- Sent via pgsql-hackers

Re: [HACKERS] WIP: generalized index constraints

, right now I'm not in a hurry to fix this last point. I realize that some of the things missing make the patch uncomittable in its current form. However, I would still appreciate a review of what I have ready. Regards, Jeff Davis generalized-index-constraints-20090915.patch.gz

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] WIP: generalized index constraints

with pg_dump, but unfortunately I haven't done either yet. I don't think it will take too much work, so I'll fix this as soon as I can. 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] WIP: generalized index constraints

constraints the conflicting tuples aren't necessarily equal. 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

think generalized unique-index constraints is a good name: it's confusing and it makes it sound like it is some new way to use a unique index. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] WIP: generalized index constraints

happens ;) 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

generalizes index constraints. However, I agree that we shouldn't use that too much in the code/docs because someone might think of something more general later. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

[HACKERS] dropping partitions and concurrent reads

invalidation correct this? 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

is not the operator itself, and throw an ERROR? Probably would be a good idea. 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

than details of the server implementation. I like this much better. Maybe index operator constraints or operator 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

Re: [HACKERS] dropping partitions and concurrent reads

On Tue, 2009-09-15 at 16:58 -0400, Tom Lane wrote: Oh? Are you using 8.4+? Oops, connecting to the wrong port. 8.5-dev works fine. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] WIP: generalized index constraints

for short (e.g. in the code and some places in the docs). 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

On Tue, 2009-09-15 at 14:42 -0700, Jeff Davis wrote: operator constraints operator exclusion constraints operator conflict constraints conflict operator constraints operator index constraints index constraints generalized index constraints something else? Just to add a couple more

Re: [HACKERS] opportunistic tuple freezing

comes when the tuples on a given page may have been inserted/updated over a few million transactions. Under normal circumstances, it won't be a huge win, but it's not a huge patch, either ;) Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

Re: [HACKERS] WIP: generalized index constraints

with that. 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

agreement from someone else. 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

generalized-constraints branch. I have psql support now, so it might be slightly easier to review. The language and name of the feature are going through a little turmoil right now, as you can see, so I'm trying to keep up with that. As that settles down I'll improve the docs. Regards, Jeff

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

to ensure that the heap file actually gets shrunk. How about we provide some way to make it acquire an access exclusive lock at the beginning, but still perform a lazy vacuum? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

: REVOKE ALL on pg_authid FROM public; 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] Feedback on getting rid of VACUUM FULL

exclusive lock if there are long-lived transactions ahead of it in the queue. We probably don't want to automate anything by default that acquires exclusive locks, even for a short time. However, I agree that it's fine in many situations if the administrator is choosing it. Regards, Jeff Davis

Re: [HACKERS] opportunistic tuple freezing

With Feedback, and then it can be resubmitted later with test results. Fine with me. I already suspected that this patch wouldn't make it to the September commitfest: http://archives.postgresql.org/pgsql-hackers/2009-09/msg00798.php Regards, Jeff Davis -- Sent via pgsql-hackers mailing

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

Re: [HACKERS] WIP: generalized index constraints

that will make any real difference, and those scenarios can be tested with gdb pretty thoroughly. 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

number when scanning the index? I'm OK with that; I don't see a lot of obvious value in having separate expressions for the constraint and the index (even if it did have value, it would take some real creativity to find it ;) Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql

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

tie the concept to implementation, because creating the index is always explicit. Peter seemed concerned about that, and I think that concern is valid, but I can live with it. If we really want them to be declarative, we could invent a new command. Regards, Jeff Davis -- Sent via

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] 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] 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] 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

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

? 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] 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] 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

<    1   2   3   4   5   6   7   8   9   10   >