[BUGS] BUG #6089: error in documentation: incorrect string literal for SSL mode; 'disabled' vs 'disable'
The following bug has been logged online: Bug reference: 6089 Logged by: Sidney Cadot Email address: sid...@jigsaw.nl PostgreSQL version: all Operating system: all Description:error in documentation: incorrect string literal for SSL mode; 'disabled' vs 'disable' Details: Table 31-3 of the documentation (Table 30-3 in older versions) lists SSL mode descriptions. Here, the mode "disabled" is mentioned. The actual, correct mode label for this is "disable" (without a 'd' at the end). See src/interfaces/libpq/fe-connect.c. This appears to be a documentation mistake that goes back to at least version 8.4. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6090: Connection problem
The following bug has been logged online: Bug reference: 6090 Logged by: zearth Email address: napoh_ke...@hotmail.com PostgreSQL version: 9 Operating system: Windows Server Standard SP2 Description:Connection problem Details: Cannot connect to routine server. Please give fast feedback! TQ. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6089: error in documentation: incorrect string literal for SSL mode; 'disabled' vs 'disable'
On Mon, Jul 4, 2011 at 16:30, Sidney Cadot wrote: > > The following bug has been logged online: > > Bug reference: 6089 > Logged by: Sidney Cadot > Email address: sid...@jigsaw.nl > PostgreSQL version: all > Operating system: all > Description: error in documentation: incorrect string literal for SSL > mode; 'disabled' vs 'disable' > Details: > > Table 31-3 of the documentation (Table 30-3 in older versions) lists SSL > mode descriptions. Here, the mode "disabled" is mentioned. > > The actual, correct mode label for this is "disable" (without a 'd' at the > end). See src/interfaces/libpq/fe-connect.c. > > This appears to be a documentation mistake that goes back to at least > version 8.4. Yup, it's a doc bug alright. It goes back to 8.4, where that table was added. I've applied a fix for this, will be in the next release. Thanks for reporting! -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6090: Connection problem
On 5/07/2011 9:35 AM, zearth wrote: The following bug has been logged online: Bug reference: 6090 Logged by: zearth Email address: napoh_ke...@hotmail.com PostgreSQL version: 9 Operating system: Windows Server Standard SP2 Description:Connection problem Details: Cannot connect to routine server. Please give fast feedback! TQ. There's no evidence that this is a bug. Please read: http://wiki.postgresql.org/wiki/Guide_to_reporting_problems ... and then post on the pgsql-general mailing list for help. -- Craig Ringer POST Newspapers 276 Onslow Rd, Shenton Park Ph: 08 9381 3088 Fax: 08 9388 2258 ABN: 50 008 917 717 http://www.postnewspapers.com.au/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6083: psql script line numbers incorrectly count \copy data
On Mon, Jul 4, 2011 at 12:02 PM, Tom Lane wrote: > "Steve Haslam" writes: >> ... Apparently, the data read from \copy >> is incrementing the script line number counter? > > Yeah, so it is. That is correct behavior for COPY FROM STDIN, > but not so much for copying from a separate file. > > The attached patch seems like an appropriate fix. However, I'm unsure > whether to apply it to released branches ... does anyone think this > might break somebody's application? I think this is pretty safe. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary"
Hello. System: PostgreSQL v9.0 Windows XP SP3 SQL: COPY "tablename" TO STDOUT WITH (FORMAT binary) ERROR: syntax error at or near "binary" LINE 1: ...OPY "tablename" TO STDOUT WITH (FORMAT binary) ^ ** Error ** ERROR: syntax error at or near "binary" SQL state: 42601 Character: 55 But if I use 'FORMAT text' or 'FORMAT csv' all is OK. Suppose this happens because BINARY is not listed in "unreserved_keyword" neither in "col_name_keyword parser" parser rules, but listed in "type_func_name_keyword" instead. -- With best wishes, Pavel mailto:pa...@gf.microolap.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary"
Excerpts from Pavel Golub's message of mar jul 05 10:52:06 -0400 2011: > Hello. > > System: PostgreSQL v9.0 Windows XP SP3 > SQL: COPY "tablename" TO STDOUT WITH (FORMAT binary) > ERROR: syntax error at or near "binary" > LINE 1: ...OPY "tablename" TO STDOUT WITH (FORMAT binary) > ^ > > ** Error ** > > ERROR: syntax error at or near "binary" > SQL state: 42601 > Character: 55 > > But if I use 'FORMAT text' or 'FORMAT csv' all is OK. > > Suppose this happens because BINARY is not listed in > "unreserved_keyword" neither in "col_name_keyword parser" parser rules, but > listed in "type_func_name_keyword" instead. That seems pretty unfortunate. Of course, it works if you quote it: COPY "tablename" TO STDOUT WITH (FORMAT "binary") I assume it's not in unreserved_keyword because it would cause a shift/reduce conflict elsewhere. -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary"
Hello, Alvaro. You wrote: AH> Excerpts from Pavel Golub's message of mar jul 05 10:52:06 -0400 2011: >> Hello. >> >> System: PostgreSQL v9.0 Windows XP SP3 >> SQL: COPY "tablename" TO STDOUT WITH (FORMAT binary) >> ERROR: syntax error at or near "binary" >> LINE 1: ...OPY "tablename" TO STDOUT WITH (FORMAT binary) >> ^ >> >> ** Error ** >> >> ERROR: syntax error at or near "binary" >> SQL state: 42601 >> Character: 55 >> >> But if I use 'FORMAT text' or 'FORMAT csv' all is OK. >> >> Suppose this happens because BINARY is not listed in >> "unreserved_keyword" neither in "col_name_keyword parser" parser rules, but >> listed in "type_func_name_keyword" instead. AH> That seems pretty unfortunate. Of course, it works if you quote it: AH> COPY "tablename" TO STDOUT WITH (FORMAT "binary") AH> I assume it's not in unreserved_keyword because it would cause a AH> shift/reduce conflict elsewhere. Well, there are two ways: 1. Change documentation, so quoted or double quoted values are accepted 2. Fix parser -- With best wishes, Pavel mailto:pa...@gf.microolap.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary"
On Tue, Jul 5, 2011 at 11:06 AM, Alvaro Herrera wrote: > Excerpts from Pavel Golub's message of mar jul 05 10:52:06 -0400 2011: >> Hello. >> >> System: PostgreSQL v9.0 Windows XP SP3 >> SQL: COPY "tablename" TO STDOUT WITH (FORMAT binary) >> ERROR: syntax error at or near "binary" >> LINE 1: ...OPY "tablename" TO STDOUT WITH (FORMAT binary) >> ^ >> >> ** Error ** >> >> ERROR: syntax error at or near "binary" >> SQL state: 42601 >> Character: 55 >> >> But if I use 'FORMAT text' or 'FORMAT csv' all is OK. >> >> Suppose this happens because BINARY is not listed in >> "unreserved_keyword" neither in "col_name_keyword parser" parser rules, but >> listed in "type_func_name_keyword" instead. > > That seems pretty unfortunate. Of course, it works if you quote it: > > COPY "tablename" TO STDOUT WITH (FORMAT "binary") > > I assume it's not in unreserved_keyword because it would cause a > shift/reduce conflict elsewhere. Yeah. In particular, it conflicts with the ancient copy syntax which we still support for backwards compatibility with versions < 7.3. We can fix the immediate problem with something like the attached. (a) Should we do that? (b) Should we back-patch it to 9.1 and 9.0? (c) Should we consider removing compatibility with the ancient copy syntax in 9.2, and de-reserving that keyword? (Given that the workaround is this simple, I'm inclined to say "no", but could be persuaded otherwise.) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company allow-copy-format-binary.patch Description: Binary data -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary"
Robert Haas writes: > On Tue, Jul 5, 2011 at 11:06 AM, Alvaro Herrera > wrote: >> I assume it's not in unreserved_keyword because it would cause a >> shift/reduce conflict elsewhere. > Yeah. In particular, it conflicts with the ancient copy syntax which > we still support for backwards compatibility with versions < 7.3. We > can fix the immediate problem with something like the attached. > (a) Should we do that? That seems like a horrid crock ... regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary"
On 07/05/2011 11:23 AM, Robert Haas wrote: Yeah. In particular, it conflicts with the ancient copy syntax which we still support for backwards compatibility with versions< 7.3. We can fix the immediate problem with something like the attached. (a) Should we do that? yes. (b) Should we back-patch it to 9.1 and 9.0? yes. (c) Should we consider removing compatibility with the ancient copy syntax in 9.2, and de-reserving that keyword? (Given that the workaround is this simple, I'm inclined to say "no", but could be persuaded otherwise.) I'm inclined to say yes, but mainly because it's just old cruft. I don't expect to be able,say, to load a pre-7.3 dump into a modern Postgres. cheers andrew -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary"
On Tue, Jul 5, 2011 at 11:30 AM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Jul 5, 2011 at 11:06 AM, Alvaro Herrera >> wrote: >>> I assume it's not in unreserved_keyword because it would cause a >>> shift/reduce conflict elsewhere. > >> Yeah. In particular, it conflicts with the ancient copy syntax which >> we still support for backwards compatibility with versions < 7.3. We >> can fix the immediate problem with something like the attached. > >> (a) Should we do that? > > That seems like a horrid crock ... Do you have something else to propose? It's a crock we have used elsewhere, so there is some precedent. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary"
Hello, Robert. You wrote: RH> On Tue, Jul 5, 2011 at 11:06 AM, Alvaro Herrera RH> wrote: >> Excerpts from Pavel Golub's message of mar jul 05 10:52:06 -0400 2011: >>> Hello. >>> >>> System: PostgreSQL v9.0 Windows XP SP3 >>> SQL: COPY "tablename" TO STDOUT WITH (FORMAT binary) >>> ERROR: syntax error at or near "binary" >>> LINE 1: ...OPY "tablename" TO STDOUT WITH (FORMAT binary) >>> ^ >>> >>> ** Error ** >>> >>> ERROR: syntax error at or near "binary" >>> SQL state: 42601 >>> Character: 55 >>> >>> But if I use 'FORMAT text' or 'FORMAT csv' all is OK. >>> >>> Suppose this happens because BINARY is not listed in >>> "unreserved_keyword" neither in "col_name_keyword parser" parser rules, but >>> listed in "type_func_name_keyword" instead. >> >> That seems pretty unfortunate. Of course, it works if you quote it: >> >> COPY "tablename" TO STDOUT WITH (FORMAT "binary") >> >> I assume it's not in unreserved_keyword because it would cause a >> shift/reduce conflict elsewhere. RH> Yeah. In particular, it conflicts with the ancient copy syntax which RH> we still support for backwards compatibility with versions < 7.3. We RH> can fix the immediate problem with something like the attached. This patch is ugly. Sorry, Robert, but it's true. RH> (a) Should we do that? RH> (b) Should we back-patch it to 9.1 and 9.0? RH> (c) Should we consider removing compatibility with the ancient copy RH> syntax in 9.2, and de-reserving that keyword? (Given that the RH> workaround is this simple, I'm inclined to say "no", but could be RH> persuaded otherwise.) +1 for this. Pre-7.3 syntax is dead in fact for many years. -- With best wishes, Pavel mailto:pa...@gf.microolap.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary"
On Tue, Jul 5, 2011 at 11:37 AM, Pavel Golub wrote: > RH> Yeah. In particular, it conflicts with the ancient copy syntax which > RH> we still support for backwards compatibility with versions < 7.3. We > RH> can fix the immediate problem with something like the attached. > > This patch is ugly. Sorry, Robert, but it's true. No hard feelings here. If you, as the reporter of the problem, don't feel that it's serious enough to warrant back-patching a fix, then I'm not going to insist. However, if we don't do what I've proposed here, then I think 8.4 and 9.0 and probably 9.1 are going to need to stay as they are, because... > RH> (c) Should we consider removing compatibility with the ancient copy > RH> syntax in 9.2, and de-reserving that keyword? (Given that the > RH> workaround is this simple, I'm inclined to say "no", but could be > RH> persuaded otherwise.) > > +1 for this. Pre-7.3 syntax is dead in fact for many years. ...this is not something we're going to back-patch. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary"
Robert Haas writes: > ... However, if we don't do what I've proposed here, > then I think 8.4 and 9.0 and probably 9.1 are going to need to stay as > they are, because... >> RH> (c) Should we consider removing compatibility with the ancient copy >> RH> syntax in 9.2, and de-reserving that keyword? (Given that the >> RH> workaround is this simple, I'm inclined to say "no", but could be >> RH> persuaded otherwise.) >> >> +1 for this. Pre-7.3 syntax is dead in fact for many years. > ...this is not something we're going to back-patch. Given the lack of prior complaints, and the simplicity of the double-quote workaround, I feel little need to have a back-patchable fix. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [HACKERS] COPY .... WITH (FORMAT binary) causes syntax error at or near "binary"
Hello, Robert. You wrote: RH> On Tue, Jul 5, 2011 at 11:37 AM, Pavel Golub wrote: >> RH> Yeah. In particular, it conflicts with the ancient copy syntax which >> RH> we still support for backwards compatibility with versions < 7.3. We >> RH> can fix the immediate problem with something like the attached. >> >> This patch is ugly. Sorry, Robert, but it's true. RH> No hard feelings here. If you, as the reporter of the problem, don't RH> feel that it's serious enough to warrant back-patching a fix, then I'm RH> not going to insist. However, if we don't do what I've proposed here, RH> then I think 8.4 and 9.0 and probably 9.1 are going to need to stay as RH> they are, because... >> RH> (c) Should we consider removing compatibility with the ancient copy >> RH> syntax in 9.2, and de-reserving that keyword? (Given that the >> RH> workaround is this simple, I'm inclined to say "no", but could be >> RH> persuaded otherwise.) >> >> +1 for this. Pre-7.3 syntax is dead in fact for many years. RH> ...this is not something we're going to back-patch. Patches needed for 9.0 and 9.1 only, because this is new format comparing with 8.x -- With best wishes, Pavel mailto:pa...@gf.microolap.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6080: information_schema.columns.column_default contains NULL inconsistently
On Sun, Jul 3, 2011 at 12:31 PM, Tom Lane wrote: > Chris Bandy writes: >> On Fri, Jul 1, 2011 at 10:35 PM, Tom Lane wrote: >>> But AFAICS there is room for implementation dependency in other cases. >>> In the particular cases you show here, PG recognizes some of them as >>> being equivalent to not having a default value, so for efficiency's sake >>> it converts them to that form. > >> That makes sense, too. Perhaps I am naive, but a null is a null, >> right? Is the different presentation of defaults for "d" and "e" >> indicative of an *in*efficiency in PG? > > Yeah, it's intentional though. What the printout is not telling you > is that there's a hidden cast function invocation to enforce the length > limit in the cases where the column has an explicit length limit. That > is, under the hood the expression is really more like "varchar(NULL, 1)". > The code that recognizes a default expression as being just constant > NULL doesn't think this is a constant NULL. In principle it could > recognize that, since the cast function is marked strict, but so far > it has not seemed worth the trouble. Gee, does Noah's recent patch adding the notion of "transform functions" have any applicability to this problem? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6080: information_schema.columns.column_default contains NULL inconsistently
Robert Haas writes: > On Sun, Jul 3, 2011 at 12:31 PM, Tom Lane wrote: >> The code that recognizes a default expression as being just constant >> NULL doesn't think this is a constant NULL. In principle it could >> recognize that, since the cast function is marked strict, but so far >> it has not seemed worth the trouble. > Gee, does Noah's recent patch adding the notion of "transform > functions" have any applicability to this problem? Not really. If someone held a gun to my head and said "fix that", what I'd do is run eval_const_expressions() on the default expression and see if that resulted in a constant NULL. But it seems unlikely to be worth the cycles in most cases. Also, we'd then need some other test to address the issue explained in AddRelationNewConstraints: /* * If the expression is just a NULL constant, we do not bother to make * an explicit pg_attrdef entry, since the default behavior is * equivalent. * * Note a nonobvious property of this test: if the column is of a * domain type, what we'll get is not a bare null Const but a * CoerceToDomain expr, so we will not discard the default. This is * critical because the column default needs to be retained to * override any default that the domain might have. */ if (expr == NULL || (IsA(expr, Const) &&((Const *) expr)->constisnull)) continue; IOW, there are cases where "DEFAULT NULL" is *not* a no-op. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6080: information_schema.columns.column_default contains NULL inconsistently
On Tue, Jul 5, 2011 at 12:42 PM, Tom Lane wrote: > Robert Haas writes: >> On Sun, Jul 3, 2011 at 12:31 PM, Tom Lane wrote: >>> The code that recognizes a default expression as being just constant >>> NULL doesn't think this is a constant NULL. In principle it could >>> recognize that, since the cast function is marked strict, but so far >>> it has not seemed worth the trouble. > >> Gee, does Noah's recent patch adding the notion of "transform >> functions" have any applicability to this problem? > > Not really. If someone held a gun to my head and said "fix that", what > I'd do is run eval_const_expressions() on the default expression and see > if that resulted in a constant NULL. But it seems unlikely to be worth > the cycles in most cases. Also, we'd then need some other test to > address the issue explained in AddRelationNewConstraints: > > /* > * If the expression is just a NULL constant, we do not bother to make > * an explicit pg_attrdef entry, since the default behavior is > * equivalent. > * > * Note a nonobvious property of this test: if the column is of a > * domain type, what we'll get is not a bare null Const but a > * CoerceToDomain expr, so we will not discard the default. This is > * critical because the column default needs to be retained to > * override any default that the domain might have. > */ > if (expr == NULL || > (IsA(expr, Const) &&((Const *) expr)->constisnull)) > continue; > > IOW, there are cases where "DEFAULT NULL" is *not* a no-op. Interesting. A possible reason to care about this is that it might convert a form of ALTER TABLE that requires a rewrite into one that doesn't, since we needn't rewrite the table if the column will be all-nulls. That's not enough of a benefit to motivate me to do the work myself, since all the examples thus-far shown involve writing the default in a way that's more complicated than necessary. But I'd have a hard time objecting if someone else wanted to run it down, since I'm pretty sure I've written an ALTER TABLE that way once or twice myself. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Re: PG regression with row comparison when btree_gist is enabled (BUG)
On Sat, 2011-07-02 at 18:38 -0400, Tom Lane wrote: > Jeff Davis writes: > > On Sat, 2011-06-18 at 13:20 -0700, Jeff Davis wrote: > >> Interesting problem... the bug is in get_op_btree_interpretation() which > >> has code like this: > >> ... > >> However, that's a bogus test, because btree_gist puts <> into an > >> opfamily. Thus, catlist->n_members == 1 even though we really do need to > >> look for the negator. Really, we need to unconditionally search for the > >> operator as well as unconditionally searching for the negator. > > > Patch attached. > > I looked at this a bit. The proposed patch is inadequate, aside from > any excess lookups it introduces, because there is similar logic in > predtest.c. To make the world safe for btree_gist to do this, we'd have > to add extra lookup activity there as well. > > Quite honestly, I think that the bug is that btree_gist took it upon > itself to invent <> as an indexable operator. The odds that that will > ever be of practical use seem negligible, and not at all adequate to > warrant adding extra cycles into mainstream code paths. It's not too > late to rip that out of 9.1, and that's what I think we should do. I think that ripping out the change to btree_gist is also insufficient; we would also have to prevent other extensions from doing the same. That means documenting an odd special case, and testing for it when defining an opclass. And then we'd probably have to backpatch this kludge. Something simpler seems possible here. The root of the problem is that we're being fooled by GiST opclasses when all we care about are BTree opclasses anyway. A simple fix would be to introduce a flag "found_btree_op". If we hit any BTree entries from pg_amop at all, then we're done after the loop is done. If not, then we negate the op and loop again. Would that be acceptable? Regards, Jeff Davis -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Re: PG regression with row comparison when btree_gist is enabled (BUG)
Jeff Davis writes: > I think that ripping out the change to btree_gist is also insufficient; > we would also have to prevent other extensions from doing the same. That > means documenting an odd special case, and testing for it when defining > an opclass. And then we'd probably have to backpatch this kludge. There is that. I doubt it's worth back-patching, though. > Something simpler seems possible here. The root of the problem is that > we're being fooled by GiST opclasses when all we care about are BTree > opclasses anyway. A simple fix would be to introduce a flag > "found_btree_op". If we hit any BTree entries from pg_amop at all, then > we're done after the loop is done. If not, then we negate the op and > loop again. Yeah, I had been thinking along the same lines. It will require duplicating the search loop, which is a bit annoying, but perhaps that could be factored out as a subroutine. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6092: specific casting required for gist indexing of bigint
The following bug has been logged online: Bug reference: 6092 Logged by: Jeff Frost Email address: j...@pgexperts.com PostgreSQL version: 9.0.4 Operating system: CentOS 5.5 Description:specific casting required for gist indexing of bigint Details: Ran into a situation with a customer who is using the btree_gist contrib module to allow combined index of some tsearch data and two other columns. One of these other columns is a bigint field. I noticed that the combined index won't be used by the planner unless you specifically cast the bare number to a bigint. Here's a quick test case: createdb jefftest psql -f /usr/pgsql-9.0/share/contrib/btree_gist.sql jefftest jefftest=# create table test (id bigint); CREATE TABLE Time: 28.541 ms jefftest=# insert into test select generate_series(1,10); INSERT 0 10 Time: 179.768 ms jefftest=# CREATE INDEX test__id ON test using gist(id) ; CREATE INDEX Time: 1603.811 ms jefftest=# ANALYZE test; ANALYZE Time: 21.854 ms jefftest=# explain analyze select id from test WHERE id = 587; QUERY PLAN Seq Scan on test (cost=0.00..1693.00 rows=500 width=8) (actual time=0.097..14.698 rows=1 loops=1) Filter: (id = 587) Total runtime: 14.739 ms (3 rows) Time: 32.965 ms jefftest=# explain analyze select id from test WHERE id = 587::bigint; QUERY PLAN Bitmap Heap Scan on test (cost=20.16..490.49 rows=500 width=8) (actual time=0.037..0.038 rows=1 loops=1) Recheck Cond: (id = 587::bigint) -> Bitmap Index Scan on test__id (cost=0.00..20.03 rows=500 width=0) (actual time=0.027..0.027 rows=1 loops=1) Index Cond: (id = 587::bigint) Total runtime: 0.080 ms (5 rows) Time: 0.592 ms -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6092: specific casting required for gist indexing of bigint
"Jeff Frost" writes: > Ran into a situation with a customer who is using the btree_gist contrib > module to allow combined index of some tsearch data and two other columns. > One of these other columns is a bigint field. I noticed that the combined > index won't be used by the planner unless you specifically cast the bare > number to a bigint. If memory serves, the btree_gist opclasses don't include any cross-type operators, so "int8 = int4" doesn't work here. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
