Re: [BUGS] BUG #1885: SHOW autovacuum settings tab completion broken
On Fri, Sep 16, 2005 at 06:02:14AM +0100, Robert Treat wrote: > PostgreSQL version: 8.1beta1 > > When doing SHOW or SHOW a none of the autovacuum > settings come up. Are you sure you're using an 8.1beta1 psql? I think tab completion were fixed to read the variable list from pg_settings before 8.1beta1 was released: http://archives.postgresql.org/pgsql-committers/2005-08/msg00151.php Here's what I get: test=> SHOW a add_missing_from authentication_timeout autovacuum_naptime autovacuum_vacuum_threshold all autovacuum autovacuum_vacuum_cost_delay archive_command autovacuum_analyze_scale_factor autovacuum_vacuum_cost_limit australian_timezones autovacuum_analyze_threshold autovacuum_vacuum_scale_factor -- Michael Fuhr ---(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 do not match
[BUGS] BUG #1886: Bug in SQL parsing
The following bug has been logged online: Bug reference: 1886 Logged by: Pete Beck Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.1 & 8.0.3 Operating system: Linux and Windows Description:Bug in SQL parsing Details: Postgres incorrectly reports a relation is being missing in a SQL. The following query reports: ERROR: relation "product0_" does not exist even though the relation is specified in the query. select category4_.id as col_0_0_, category4_.description as col_1_0_, category4_.long_description as col_2_0_, product0_.product_type_id as col_4_0_, attributev7_.string_value as col_5_0_, attributev7_.string_value as col_6_0_, attributev7_.integer_value as col_7_0_ from ( select created, sort_order, product_type_id, currency_id, unit_cost, product_status_id, name, updated, id, 0 as clazz_ from product union all select created, sort_order, product_type_id, currency_id, unit_cost, product_status_id, name, updated, id, 1 as clazz_ from user_product ) product0_ left outer join ( select created, index, attribute_value_id, product_id, updated, name, 0 as clazz_ from product_attribute union all select created, index, attribute_value_id, product_id, updated, name, 1 as clazz_ from user_product_attribute ) productatt1_ on product0_.id=productatt1_.product_id, ( select integer_value, created, boolean_value, attribute_type_id, date_value, float_value, string_value, updated, id, 0 as clazz_ from squashed_attribute_value union all select integer_value, created, boolean_value, attribute_type_id, date_value, float_value, string_value, updated, id, 1 as clazz_ from user_squashed_attribute_value ) attributev7_ left outer join ( select created, index, attribute_value_id, product_id, updated, name, 0 as clazz_ from product_attribute union all select created, index, attribute_value_id, product_id, updated, name, 1 as clazz_ from user_product_attribute ) productatt2_ on product0_.id=productatt2_.product_id left outer join ( select created, index, attribute_value_id, product_id, updated, name, 0 as clazz_ from product_attribute union all select created, index, attribute_value_id, product_id, updated, name, 1 as clazz_ from user_product_attribute ) productatt3_ on product0_.id=productatt3_.product_id, category category4_, product_category productcat5_, product_category productcat6_ where productatt1_.attribute_value_id=attributev7_.id and productcat5_.product_id=product0_.id and productcat5_.category_id=category4_.id and category4_.category_type_id=4 and productcat6_.product_id=product0_.id and productatt1_.name='description' and productatt1_.index=1 and productatt2_.name='long_description' and productatt2_.index=1 and productatt3_.name='icon_id' and productatt3_.index=1 and productcat6_.category_id=190; Here is a schema which you can use in an empty database to reproduce the error: -- -- TOC entry 1512 (class 1259 OID 76062319) -- Dependencies: 2070 2071 5 -- Name: base_object; Type: TABLE; Schema: public; Owner: appserver; Tablespace: -- CREATE TABLE base_object ( created timestamp with time zone DEFAULT now() NOT NULL, updated timestamp with time zone DEFAULT now() NOT NULL ); -- CREATE TABLE attribute ( attribute_value_id integer NOT NULL, "index" integer NOT NULL, name text NOT NULL
[BUGS] BUG #1887: "Fillinvalues failed" error : PgOledb 1.0.0.19 with Postgres 8.1 Beta
The following bug has been logged online:
Bug reference: 1887
Logged by: Viswanath Ramineni
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1 Beta
Operating system: Windows 2000 Prof
Description:"Fillinvalues failed" error : PgOledb 1.0.0.19 with
Postgres 8.1 Beta
Details:
Parameter data type is OleDbType.VarChar, direction is input. Following is
the sql I am running..
select
USERID,USERNAME,USERDESCR,PASSWORD,VALIDFROM,VALIDTO,STATUS,CREATEDBY,CREATE
DDATE,LASTUPDBY,LASTUPDDATE from APPUSER Where USERNAME = ?
When I hard code the value for username instead of using the parameter ('?')
it works fine. Other wise I get the "Fillinvalues failed" error.
Currently our application is supported on Oracle and SqlServer. I am trying
to provide support on Postgres also. Because of the need to use multiple
"out parameters" in plpgsql, I cannot use earlier versions of Postgres, I
have to use only 8.1. Unable to move further because of this error coupled
with Bug#1860 (proble with unique index) I posted here. Please help.
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #1886: Bug in SQL parsing
On Fri, 16 Sep 2005, Pete Beck wrote: > > The following bug has been logged online: > > Bug reference: 1886 > Logged by: Pete Beck > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.0.1 & 8.0.3 > Operating system: Linux and Windows > Description:Bug in SQL parsing > Details: > > Postgres incorrectly reports a relation is being missing in a SQL. > > The following query reports: > > ERROR: relation "product0_" does not exist I believe this error is correct. It looks to me like you have: A Left join B on condition, C left join D on condition2 where condition2 refers to A. IIRC, in standard SQL, the scope for condition contains A and B and the scope for condition2 contains C and D but not A. ---(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 do not match
Re: [BUGS] BUG #1885: SHOW autovacuum settings tab completion broken
On Friday 16 September 2005 09:00, Michael Fuhr wrote:
> On Fri, Sep 16, 2005 at 06:02:14AM +0100, Robert Treat wrote:
> > PostgreSQL version: 8.1beta1
> >
> > When doing SHOW or SHOW a none of the autovacuum
> > settings come up.
>
> Are you sure you're using an 8.1beta1 psql? I think tab completion
> were fixed to read the variable list from pg_settings before 8.1beta1
> was released:
>
Doh!
postgres=# select version();
version
PostgreSQL 8.1devel on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.3.3
20040412 (Red Hat Linux 3.3.3-7)
At 1 AM that sure looked like 8.1beta1 :-( Guess that explains why the code
looked correct... course I gotta wonder about whoever it was on irc that
"confirmed" the problem for me :-) Thanks Michael.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(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: [BUGS] BUG #1862: ECPG Connect, host variable trailing blanks
[EMAIL PROTECTED] wrote: > What do you think of an Postgres option that would enable stripping of > trailing blanks from connect host variables when turned ON? I would not support such an option. If we added flags for every single thing that someone wanted, the system would be unusable. > This would allow current behavior to be supported by ECPG and the > Postgres server, but allow applications that need the behavior (like > a Cobol/SQL preprocessor for Postgres), to make use of it. > > When I searched the mail archives, I found that others had run into > this same problem, in this case with an ODBC driver: >http://archives.postgresql.org/pgsql-interfaces/1998-08/msg0.php Just because Oracle does it doesn't mean we should. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #1862: ECPG Connect, host variable trailing blanks
On Fri, Sep 16, 2005 at 12:00:59PM -0400, Bruce Momjian wrote: > [EMAIL PROTECTED] wrote: > > What do you think of an Postgres option that would enable stripping of > > trailing blanks from connect host variables when turned ON? > > I would not support such an option. If we added flags for every single > thing that someone wanted, the system would be unusable. [snip] > Just because Oracle does it doesn't mean we should. Does Oracle really munge data on the client side? Or does it, like PostgreSQL, pass the host variable's value as-is to the server, and the server considers trailing spaces significant or not depending on the context? Is it the client-side behavior or the server-side behavior that's different between PostgreSQL and Oracle? If Oracle strips trailing spaces on the client side, is that a configurable option? How would you insert significant trailing spaces into a VARCHAR column if the client library strips them? -- Michael Fuhr ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #1871: operations with data types
Added to TODO: o Fix SELECT INTERVAL '1' MONTH; --- Tom Lane wrote: > Michael Fuhr <[EMAIL PROTECTED]> writes: > > I just noticed something in PostgreSQL that might be considered > > surprising (although I do see "Add ISO INTERVAL handling" in the > > TODO list): > > > test=> select interval '1' month; > >interval > > -- > >00:00:00 > > (1 row) > > > What's the parser doing here? > > Not getting it right ;-). Trying this in historical versions is > amusing: > > 7.0: > regression=# select interval '1' month; > ERROR: parser: parse error at or near "month" > > 7.1: > regression=# select interval '1' month; > ERROR: Bad interval external representation '1' > > 7.2: > regression=# select interval '1' month; > interval > -- > 00:00 > (1 row) > > 7.3: > regression=# select interval '1' month; > interval > -- > 00:00:01 > (1 row) > > 7.4 and up: > regression=# select interval '1' month; > interval > -- > 00:00:00 > (1 row) > > What is happening in the current versions is that coerce_type thinks > it can coerce the literal string to interval without supplying the > modifier, and then use interval_scale() to apply the typmod. This > works OK for most of the data types, but not for interval it seems... > > Basically the support for these weird syntaxes is something that Tom > Lockhart never finished, and no one has bothered to pick up the work > since he left the project. > > regards, tom lane > > ---(end of broadcast)--- > TIP 3: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faq > -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
