[HACKERS] pg_restore & search_path, COPY failed for table "mytable": ERROR: function myinnerfunction(integer) does not exist
Hi, The following steps reproduce an error with pg_restore: DROP TABLE IF EXISTS myTable; DROP FUNCTION IF EXISTS myInnerFunction(INTEGER); DROP FUNCTION IF EXISTS myOuterFunction(INTEGER); DROP SCHEMA IF EXISTS myOtherSchema; CREATE SCHEMA myOtherSchema; SET search_path = myPrimarySchema, myOtherSchema, public; CREATE OR REPLACE FUNCTION myOtherSchema.myInnerFunction(INTEGER) RETURNS boolean LANGUAGE sql IMMUTABLE STRICT AS $$ SELECT TRUE; $$; CREATE OR REPLACE FUNCTION myOuterFunction(INTEGER) RETURNS boolean LANGUAGE sql IMMUTABLE STRICT AS $$ SELECT myInnerFunction($1); $$; CREATE TABLE myTable( mycol INTEGER, CONSTRAINT MyConstraint CHECK (myOuterFunction(mycol)) ); INSERT INTO myTable VALUES (1); Do a pg_dump of myTable. Doing a pg_restore, throws: COPY failed for table "mytable": ERROR: function myinnerfunction(integer) does not exist LINE 2: SELECT myInnerFunction($1); ^ HINT: No function matches the given name and argument types. You might need to add explicit type casts. QUERY: SELECT myInnerFunction($1); CONTEXT: SQL function "myouterfunction" during inlining Using pg_dump plain on myTable shows that search_path is set to myPrimarySchema, pg_catalog, so is missing myOtherSchema. I'm puzzled as to how search_path should be used,. Should all references be schema qualified inside functions body ? Or is search_path safe except in the body of functions used in index or constraints ? That's with version 9.5.3 & 9.6 beta 3. Thanks, Jean-Pierre Pelletier -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] The link to download PostgreSQL 9.6 Beta 2 for Windows X64 is broken (The link downloads Beta 1)
The link to download PostgreSQL 9.6 Beta 2 for Windows X64 is not working. The link does download something, but it's Beta 1. http://www.enterprisedb.com/products-services-training/pgdownload#windows Thanks, Jean-Pierre Pelletier
Re: [HACKERS] Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?
If instead of casts, functions to_tsvector() and to_tsquery() are used,
then the results is (I think ?) as expected:
select to_tsvector('simple', 'cat bat fat rat') @@ to_tsquery('simple',
'cat <-> rat');
or
select to_tsvector('simple', 'rat cat bat fat') @@ to_tsquery('simple',
'cat <-> rat');
returns "false"
select to_tsvector('simple', 'cat rat bat fat') @@ to_tsquery('simple',
'cat <-> rat');
returns "true"
Jean-Pierre Pelletier
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Wednesday, June 8, 2016 1:12 PM
To: Teodor Sigaev; Oleg Bartunov
Cc: Jean-Pierre Pelletier; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Should phraseto_tsquery('simple', 'blue blue') @@
to_tsvector('simple', 'blue') be true ?
Another thing I noticed: if you test with tsvectors that don't contain
position info, <-> seems to reduce to &, that is it doesn't enforce
relative position:
regression=# select 'cat bat fat rat'::tsvector @@ 'cat <-> rat'::tsquery;
?column?
--
t
(1 row)
regression=# select 'rat cat bat fat'::tsvector @@ 'cat <-> rat'::tsquery;
?column?
--
t
(1 row)
I'm doubtful that this is a good behavior, because it seems like it can
silently mask mistakes. That is, applying <-> to a stripped tsvector
seems like user error to me. Actually throwing an error might be too
much, but perhaps we should make such cases return false not true?
(This is against HEAD, without the patch I suggested yesterday.
It strikes me that that patch might change this behavior, if the lexemes
are all being treated as having position zero, but I have not checked.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?
Hi,
I wanted to test if phraseto_tsquery(), new with 9.6 could be used for
matching consecutive words but it won't work for us if it cannot handle
consecutive *duplicate* words.
For example, the following returns true:select
phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue');
Is this expected ?
Thanks,
Jean-Pierre Pelletier
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Number of parentheses in check constraints affected by operator_precedence_warning
Hi, We noticed on PostgreSQL 9.5.3 that the number of parentheses in check constraints expressions vary depending on the setting of operator_precedence_warning. -- The following reproduces this issue which we first saw by restoring into 9.5.3 a 9.4.8 dump on two servers which had different operator_precedence_warning. SET operator_precedence_warning = off; -- on would yield a different number of parentheses DROP TABLE IF EXISTS t1; CREATE TABLE t1 (col1 INT, col2 INT, col3 INT, col4 INT); -- 1) Check Constraints ALTER TABLE t1 ADD CONSTRAINT cc1 CHECK ((col1 IS NULL) OR (((col2 IS NULL) AND (col3 IS NULL)) AND (col4 IS NULL))), ADD CONSTRAINT cc2 CHECK (((col1 IS NOT NULL) OR (col2 IS NOT NULL)) OR (col3 IS NOT NULL)); SELECT conname, consrc FROM pg_constraint WHERE conrelid = 't1'::regclass; -- With 9.5.3 operator_precedence_warning = on (or pg 9.4) -- cc1 ((col1 IS NULL) OR (((col2 IS NULL) AND (col3 IS NULL)) AND (col4 IS NULL))) -- cc2 (((col1 IS NOT NULL) OR (col2 IS NOT NULL)) OR (col3 IS NOT NULL)) -- With 9.5.3 operator_precedence_warning = off -- cc1 ((col1 IS NULL) OR ((col2 IS NULL) AND (col3 IS NULL) AND (col4 IS NULL))) -- cc2 ((col1 IS NOT NULL) OR (col2 IS NOT NULL) OR (col3 IS NOT NULL)) -- 2) WHEN condition on triggers also have this issue, for example: DROP FUNCTION IF EXISTS f1(); CREATE FUNCTION f1() RETURNS trigger LANGUAGE plpgsql AS $$ BEGIN END; $$; CREATE TRIGGER tr1 BEFORE UPDATE ON t1 FOR EACH ROW WHEN (new.col1 IS DISTINCT FROM old.col1) OR (new.col2 IS DISTINCT FROM old.col2)) OR ((new.col3 IS NOT NULL) AND (new.col3 IS DISTINCT FROM old.col3))) OR ((new.col3 IS NULL) AND (new.col3 IS DISTINCT FROM old.col3 EXECUTE PROCEDURE f1(); We got these results on Windows x64. Thanks, Jean-Pierre Pelletier -- 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] Declarative partitioning
Why not based it on "Exclusion Constraint" ? Most discussions as of late seems to focus on Range overlaps which appeal (I would think) is that it supports both "equality" and "overlaps", two popular partitioning schemes. "Equality" as in "value1 = value2" can be implemented with "range overlaps" as "range(value1,value) = range(value,value2)". I would think that Partitioning schemes can be Declarative, Efficient and not restricted to Equality and Overlaps as long as all partitions (of a partitioned table) are using a single partitioning definition expressed as: - An Immutable Expression on tuple columns, in the simplest case a single column - An Operator, in the simplest case, "equality" That seems very close to the semantic of "Constraint Exclusion" as described here: http://thoughts.davisjeff.com/2010/09/25/exclusion-constraints-are-general ized-sql-unique/ If partitioning could be based on EC, it would bring these additional benefits: - The choice of operator as long as it is boolean. commutative and Indexable - The use of Expression/Function and not just bare columns Jean-Pierre Pelletier -- 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] Declarative partitioning
Why not based it on "Exclusion Constraint" ? Most discussions as of late seems to focus on Range overlaps which appeal (I would think) is that it supports both "equality" and "overlaps", two popular partitioning schemes. "Equality" as in "value1 = value2" can be implemented with "range overlaps" as "range(value1,value) = range(value,value2)". I would think that Partitioning schemes can be Declarative, Efficient and not restricted to Equality and Overlaps as long as all partitions (of a partitioned table) are using a single partitioning definition expressed as: - An Immutable Expression on tuple columns, in the simplest case a single column - An Operator, in the simplest case, "equality" That seems very close to the semantic of "Constraint Exclusion" as described here: http://thoughts.davisjeff.com/2010/09/25/exclusion-constraints-are-general ized-sql-unique/ If partitioning could be based on EC, it would bring these additional benefits: - The choice of operator as long as it is boolean. commutative and Indexable - The use of Expression/Function and not just bare columns Jean-Pierre Pelletier -- 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] ALTER TABLE INHERIT vs collations
One use case for this might be with constraint exclusion where there would be one partition per collation (language) with queries against the parent table always being for exactly one language. Not sure what the collation should be in the parent table then. -- 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] temporal variants of generate_series()
Here's a shorter version:
On the date variant, I wasn't sure how to handle intervals with parts
smaller than days:
floor, ceiling, round or error out
To get round, the last parameters of generate_series would be
extract('epoch' FROM '1 day'::interval)::bigint * round(extract('epoch' FROM
$3) / extract('epoch' FROM '1 day'::interval))::bigint
CREATE OR REPLACE FUNCTION generate_series (
start_ts timestamptz,
end_ts timestamptz,
step interval
) RETURNS SETOF timestamptz
STRICT
LANGUAGE sql
AS $$
SELECT
'epoch'::timestamptz + s.i * '1 second'::interval AS generate_series
FROM
generate_series(
extract('epoch' FROM $1)::bigint,
extract('epoch' FROM $2)::bigint,
extract('epoch' FROM $3)::bigint
) s(i);
$$;
CREATE OR REPLACE FUNCTION generate_series (
start_ts date,
end_ts date,
step interval
) RETURNS SETOF date
STRICT
LANGUAGE sql
AS $$
SELECT
('epoch'::date + s.i * '1 second'::interval)::date AS generate_series
FROM
generate_series(
extract('epoch' FROM $1)::bigint,
extract('epoch' FROM $2)::bigint,
extract('epoch' FROM date_trunc('day', $3))::bigint -- does a floor
) s(i);
$$;
Jean-Pierre Pelletier
e-djuster
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Re: [HACKERS] temporal variants of generate_series()
Here's a shorter version:
On the date variant, I wasn't sure how to handle intervals with parts
smaller than days:
floor, ceiling, round or error out
To get round, the last parameters of generate_series would be
extract('epoch' FROM '1 day'::interval)::bigint * round(extract('epoch' FROM
$3) / extract('epoch' FROM '1 day'::interval))::bigint
CREATE OR REPLACE FUNCTION generate_series (
start_ts timestamptz,
end_ts timestamptz,
step interval
) RETURNS SETOF timestamptz
STRICT
LANGUAGE sql
AS $$
SELECT
'epoch'::timestamptz + s.i * '1 second'::interval AS generate_series
FROM
generate_series(
extract('epoch' FROM $1)::bigint,
extract('epoch' FROM $2)::bigint,
extract('epoch' FROM $3)::bigint
) s(i);
$$;
CREATE OR REPLACE FUNCTION generate_series (
start_ts date,
end_ts date,
step interval
) RETURNS SETOF date
STRICT
LANGUAGE sql
AS $$
SELECT
('epoch'::date + s.i * '1 second'::interval)::date AS generate_series
FROM
generate_series(
extract('epoch' FROM $1)::bigint,
extract('epoch' FROM $2)::bigint,
extract('epoch' FROM date_trunc('day', $3))::bigint -- does a floor
) s(i);
$$;
Jean-Pierre Pelletier
e-djuster
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
[HACKERS] log_min_error_statement and parameters value
Hi, In PostgreSQL 8.2, log_statement display actual parameters value which is very neat as in DETAIL: parameters: $1 = '1', $2 = NULL Currently I used log_statement='all' to display all statements and their parameters but that produced a lot of output and I am really only interested in the statements displayed with log_min_error_statement. Is it possible to set log_min_error_statement to display the parameters value? Thanks, Jean-Pierre Pelletier e-djuster ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Index ignored with is not distinct from, 8.2 beta2
I can see that adding null to indexes would allow all cases of is not distinct from to use them. The lack of null in indexes would explain why a condition such as col is not distinct from null would not pick up an index. But my example was: col is not distinct from 123 and the equivalent longer form has no problem picking up the index I could restate the problem as: Why can't the planner handle col is not distinct from 123 as well as col is not null and 123 is not null and col = 123 or col is null and 123 is null Jean-Pierre Pelletier From: Martijn van Oosterhout kleptog@svana.org Reply-To: Martijn van Oosterhout kleptog@svana.org To: JEAN-PIERRE PELLETIER [EMAIL PROTECTED] CC: [EMAIL PROTECTED], pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Index ignored with is not distinct from, 8.2 beta2 Date: Tue, 7 Nov 2006 11:03:42 +0100 On Mon, Nov 06, 2006 at 09:10:40PM -0500, JEAN-PIERRE PELLETIER wrote: I understand that the planner doesn't use indexes for IS NOT DISTINCT FROM, but it would be good because is not distinct from is very useful when you have nulls but don't want to use three value logic. The main issue is that currently indexes cannot be used to find NULLs in a table. Patches have been created that cover most index types, but it's not part of the main distribution. Partial indexes can be a solution to the x IS NULL clauses. Hope this helps, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Index ignored with is not distinct from, 8.2 beta2
This shows all three forms to be equivalent. SELECT exp1, exp2, exp1 IS NOT DISTINCT FROM exp2 AS isnotdistinct, exp1 is not null and exp2 is not null and exp1 = exp2 or exp1 is null and exp2 is null AS JP, (exp1 is not null and exp2 is not null and exp1 = exp2) or (exp1 is null and exp2 is null) AS Jim FROM (SELECT 1 AS exp1, 1 AS exp2 UNION ALL SELECT 1, 2 UNION ALL SELECT 1,NULL UNION ALL SELECT NULL,1 UNION ALL SELECT NULL,NULL) Q; I understand that the planner doesn't use indexes for IS NOT DISTINCT FROM, but it would be good because is not distinct from is very useful when you have nulls but don't want to use three value logic. null = null = true null = not null = false I don't think it is that uncommon and even some SQL constructs such as select distinct or group by compare null that way. I'll wait before using IS NOT DISTINCT FROM and stick with the equivalent longer forms which use indexes. 8.2 is better than 8.1 which was not picking up indexes even with the longer forms. Jean-Pierre Pelletier From: Jim C. Nasby [EMAIL PROTECTED] To: JEAN-PIERRE PELLETIER [EMAIL PROTECTED] CC: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Index ignored with is not distinct from, 8.2 beta2 Date: Mon, 6 Nov 2006 16:02:40 -0600 One issue is that I'm not sure think you've got your sugar quite right. Have you tested with: (col IS NOT NULL AND 123 IS NOT NULL AND col = 123) OR (col IS NULL and 123 IS NULL) ? It's possible that the planner doesn't know about using an index for DISTINCT; or it might just want an index that's defined WHERE col IS NOT NULL. On Wed, Nov 01, 2006 at 03:29:33PM -0500, JEAN-PIERRE PELLETIER wrote: I've reposted this from pgsql-performance where I got no response. == Hi, I wanted to use exp1 is not distinct from exp2 which I tough was syntaxic sugar for exp1 is not null and exp2 is not null and exp1 = exp2 or exp1 is null and exp2 is null but my index is ignored with is not distinct from. Is this the expected behavior ? create temporary table t as select * from generate_series(1,100) t(col); create unique index i on t(col); analyze t; -- These queries don't use the index select count(*) from t where col is not distinct from 123; select count(*) from t where not col is distinct from 123; -- This query use the index select count(*) from t where col is not null and 123 is not null and col = 123 or col is null and 123 is null; explain analyze select count(*) from t where col is not distinct from 123; QUERY PLAN Aggregate (cost=19154.79..19154.80 rows=1 width=0) (actual time=228.200..228.202 rows=1 loops=1) - Seq Scan on t (cost=0.00..17904.90 rows=499956 width=0) (actual time=0.042..228.133 rows=1 loops=1) Filter: (NOT (col IS DISTINCT FROM 123)) Total runtime: 228.290 ms (4 rows) Time: 219.000 ms explain analyze select count(*) from t where not col is distinct from 123; QUERY PLAN Aggregate (cost=19154.79..19154.80 rows=1 width=0) (actual time=235.950..235.952 rows=1 loops=1) - Seq Scan on t (cost=0.00..17904.90 rows=499956 width=0) (actual time=0.040..235.909 rows=1 loops=1) Filter: (NOT (col IS DISTINCT FROM 123)) Total runtime: 236.065 ms (4 rows) Time: 250.000 ms explain analyze select count(*) from t where col is not null and 123 is not null and col = 123 or col is null and 123 is null; QUERY PLAN --- Aggregate (cost=8.13..8.14 rows=1 width=0) (actual time=0.267..0.268 rows=1 loops=1) - Index Scan using i on t (cost=0.00..8.13 rows=1 width=0) (actual time=0.237..0.241 rows=1 loops=1) Index Cond: (col = 123) Total runtime: 0.366 ms (4 rows) Time: 0.000 ms I am on Windows XP Service pack 2 with PostgreSQL 8.2 beta2 Thanks, Jean-Pierre Pelletier e-djuster ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] Index ignored with is not distinct from, 8.2 beta2
I've reposted this from pgsql-performance where I got no response. == Hi, I wanted to use exp1 is not distinct from exp2 which I tough was syntaxic sugar for exp1 is not null and exp2 is not null and exp1 = exp2 or exp1 is null and exp2 is null but my index is ignored with is not distinct from. Is this the expected behavior ? create temporary table t as select * from generate_series(1,100) t(col); create unique index i on t(col); analyze t; -- These queries don't use the index select count(*) from t where col is not distinct from 123; select count(*) from t where not col is distinct from 123; -- This query use the index select count(*) from t where col is not null and 123 is not null and col = 123 or col is null and 123 is null; explain analyze select count(*) from t where col is not distinct from 123; QUERY PLAN Aggregate (cost=19154.79..19154.80 rows=1 width=0) (actual time=228.200..228.202 rows=1 loops=1) - Seq Scan on t (cost=0.00..17904.90 rows=499956 width=0) (actual time=0.042..228.133 rows=1 loops=1) Filter: (NOT (col IS DISTINCT FROM 123)) Total runtime: 228.290 ms (4 rows) Time: 219.000 ms explain analyze select count(*) from t where not col is distinct from 123; QUERY PLAN Aggregate (cost=19154.79..19154.80 rows=1 width=0) (actual time=235.950..235.952 rows=1 loops=1) - Seq Scan on t (cost=0.00..17904.90 rows=499956 width=0) (actual time=0.040..235.909 rows=1 loops=1) Filter: (NOT (col IS DISTINCT FROM 123)) Total runtime: 236.065 ms (4 rows) Time: 250.000 ms explain analyze select count(*) from t where col is not null and 123 is not null and col = 123 or col is null and 123 is null; QUERY PLAN --- Aggregate (cost=8.13..8.14 rows=1 width=0) (actual time=0.267..0.268 rows=1 loops=1) - Index Scan using i on t (cost=0.00..8.13 rows=1 width=0) (actual time=0.237..0.241 rows=1 loops=1) Index Cond: (col = 123) Total runtime: 0.366 ms (4 rows) Time: 0.000 ms I am on Windows XP Service pack 2 with PostgreSQL 8.2 beta2 Thanks, Jean-Pierre Pelletier e-djuster ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [JDBC] server process (PID 1188) exited with exit code
) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:831) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:639) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1196) at java.lang.Thread.run(Unknown Source) SQLException: SQLState(08006) From: Oliver Jowett [EMAIL PROTECTED] To: Tom Lane [EMAIL PROTECTED] CC: Dave Cramer [EMAIL PROTECTED], JEAN-PIERRE PELLETIER [EMAIL PROTECTED], List pgsql-jdbc@postgresql.org, PostgreSQL-development pgsql-hackers@postgresql.org Subject: Re: [HACKERS] [JDBC] server process (PID 1188) exited with exit code Date: Wed, 25 Oct 2006 03:26:07 + Tom Lane wrote: NULL,/* let the backend deduce param type */ I think the JDBC driver will be passing the int4 OID for the param type in this case. Best thing is probably for the OP to run with loglevel=2 and see exactly what's being sent, though. -O ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [JDBC] server process (PID 1188) exited with exit code
Yes, the problem is gone in 8.2 beta2.
Thanks all for an outstanding product and support,
Jean-Pierre Pelletier
From: Tom Lane [EMAIL PROTECTED]
To: JEAN-PIERRE PELLETIER [EMAIL PROTECTED]
CC: pgsql-hackers@postgresql.org, [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [HACKERS] [JDBC] server process (PID 1188) exited with exit
code Date: Wed, 25 Oct 2006 10:15:03 -0400
JEAN-PIERRE PELLETIER [EMAIL PROTECTED] writes:
08:47:19.296 (1) FE= Parse(stmt=null,query=select $1 from (select *
from
pg_database) t,oids={23})
Actually, now that I look closely, this command is almost certainly
triggering this beta1 bug:
http://archives.postgresql.org/pgsql-committers/2006-10/msg00107.php
Please try beta2 and see if it isn't fixed.
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
