Re: [BUGS] BUG #7661: pgstattuple from unpackaged fails on old installation

[Craig Ringer]

On 11/15/2012 03:32 PM, Stuart Bishop wrote:
>> That's a known issue with several of the extensions. You need to upgrade
>> the contrib module install to the current version, *then* wrap the
>> unpackaged contrib module into an extension with "FROM UNPACKAGED".
> Yeah, just thought I'd stick it in the... umm... bugtracker, as so far
> 'FROM unpackaged' has failed in 66% of up updates. Is the real
> solution is for the foo--unpackaged--1.0.sql script to recreate
> missing objects before adding them to the extension?
For simple extensions running the create script should do the job, yes.
It's not so clear cut for extensions that define data types, though.

If I recall correctly the general advice for those has been to:

- Create the new versions of extensions in the DB you're going to
restore to; then
- restore your database to that DB with the extensions pre-created in it.

I'm surprised not to find any documentation on coping with this issue in:

  http://www.postgresql.org/docs/current/static/contrib.html

or
  http://www.postgresql.org/docs/current/static/extend-extensions.html


(though it's possible it's there and I missed it).

There used to be brief mention in contrib.html before the extensions
changes went in, saying:

"After a major-version upgrade of PostgreSQL, run the installation
script again, even though the module's objects might have been brought
forward from the old installation by dump and restore. This ensures that
any new functions will be available and any needed corrections will be
applied."

... but I'm not certain that advice is sufficient for all contrib modules.

Extensions were created because upgrading DBs that used contrib modules
was a painful mess.


-- 
 Craig Ringer   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Re: [BUGS] BUG #7661: pgstattuple from unpackaged fails on old installation

[Tom Lane]

Craig Ringer  writes:
> On 11/15/2012 03:32 PM, Stuart Bishop wrote:
>>> That's a known issue with several of the extensions. You need to upgrade
>>> the contrib module install to the current version, *then* wrap the
>>> unpackaged contrib module into an extension with "FROM UNPACKAGED".

>> Yeah, just thought I'd stick it in the... umm... bugtracker, as so far
>> 'FROM unpackaged' has failed in 66% of up updates. Is the real
>> solution is for the foo--unpackaged--1.0.sql script to recreate
>> missing objects before adding them to the extension?

> Extensions were created because upgrading DBs that used contrib modules
> was a painful mess.

Yeah.  The goal we set ourselves when making the foo--unpackaged scripts
was only to be able to upgrade from the immediately preceding form of
the contrib module.  I think it's probably true that in many cases
adding CREATE OR REPLACE-type commands could allow upgrading from
earlier versions as well.  But it would be a lot of work to research
what's needed and create/test a patch, and it would be work whose value
lessens with every passing day.  If there's somebody out there who's
sufficiently annoyed to do that work, have at it.

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 #7662: INSERT rule doesn't work as expected

[mtesfaye]

The following bug has been logged on the website:

Bug reference:  7662
Logged by:  Melese Tesfaye
Email address:  mtesf...@gmail.com
PostgreSQL version: 9.2.1
Operating system:   FreeBSD 9.0-RELEASE
Description:

ON INSERT RULE doesn't always work as expected.
The reasoning for this particular rule was to add the new value to an
existing value if it is determined that the key already exists.

Here is the table definition:

CREATE TABLE test_r(id INT PRIMARY KEY,val INT NOT NULL);

Here is the rule definition:

CREATE OR REPLACE RULE "dup_add_test_r_rule" AS 
  ON INSERT TO test_r
  WHERE 
EXISTS(SELECT 1 FROM test_r a WHERE a.id=NEW.id) 
DO INSTEAD 
   (UPDATE test_r a SET val=a.val+NEW.val WHERE a.id=NEW.id);

Empty table:
   
SELECT * FROM test_r;

++-+
| id | val |
++-+
++-+
(0 rows)

Time: 0.775 ms

Now, insert the following.

INSERT INTO test_r VALUES(1,10);
INSERT 0 1
Time: 2.038 ms

Query the table after insert (expected val to be 10 since the rule would
have
been igonred as id 1 didn't exist prior to inserting.

SELECT * FROM test_r;
++-+
| id | val |
++-+
|  1 |  20 |
++-+
(1 row)





-- 
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 #7662: INSERT rule doesn't work as expected

[Tom Lane]

mtesf...@gmail.com writes:
> ON INSERT RULE doesn't always work as expected.
> The reasoning for this particular rule was to add the new value to an
> existing value if it is determined that the key already exists.

> CREATE OR REPLACE RULE "dup_add_test_r_rule" AS 
>   ON INSERT TO test_r
>   WHERE 
> EXISTS(SELECT 1 FROM test_r a WHERE a.id=NEW.id) 
> DO INSTEAD 
>(UPDATE test_r a SET val=a.val+NEW.val WHERE a.id=NEW.id);

Per the manual:

For ON INSERT rules, the original query (if not suppressed by INSTEAD)
is done before any actions added by rules. This allows the actions to
see the inserted row(s). 

So the behavior in your example is 

(1) The EXISTS test fails, so the INSERT is allowed to execute.

(2) Now the EXISTS test passes, so the UPDATE is allowed to execute.

This might not be what you wished would happen, but it's not a bug;
it's the way rules are defined to work.  You might have better luck
with a BEFORE INSERT trigger.

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 #7651: Superfluous calls to functions used for indexing

[Jeff Davis]

On Sun, 2012-11-11 at 15:45 +, m...@8d.no wrote:
> Bug: When making an index over a function, then selecting a result that does
> not contain the function call (but orders on it), Superfluous function calls
> are made. This possibly because the plan creates a projection containing the
> function value.

It's possible that the function call may be unnecessary, but that is
more of a performance enhancement, not a bug.

Also, the example function has side effects. If you declare functions
with side effects to be IMMUTABLE, you can get all kinds of problems.
You should certainly not rely on an IMMUTABLE function to be called a
specific number of times.

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

[BUGS] BUG #7664: Program using libpq and ecpglib can not output native language

[chenhj]

The following bug has been logged on the website:

Bug reference:  7664
Logged by:  Chen Huajun
Email address:  che...@cn.fujitsu.com
PostgreSQL version: 9.1.6
Operating system:   Linux
Description:

The error messages output by libpq or ecpglib is always be english. But my
expect is my native language.

Step:
1)compile my program which linked to libpq or ecpglib.
2)set my locale to native language.
set LANG=ja_JP.UTF-8
set LC_ALL=ja_JP.UTF-8
3)run my program and let it raise an error.

I knows reason. The default locale of a program is "C" in Linux,regardless
the Environment Variables.
if add the following line in my program,everything is OK.

setlocale(LC_ALL, "");

But I found no document tell users should do so.And I think it's not a easy
way.Can libpq and ecpglib do it for users?

*）Windows is OK.Solaris may has the same problem.



-- 
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 #7651: Superfluous calls to functions used for indexing

[Stuart Bishop]

On Sun, Nov 11, 2012 at 10:45 PM,   wrote:

> Bug: When making an index over a function, then selecting a result that does
> not contain the function call (but orders on it), Superfluous function calls
> are made. This possibly because the plan creates a projection containing the
> function value.

I think this is the same issue as was discussed here, dating from
PostgreSQL 8.1:

http://postgresql.1045698.n5.nabble.com/Slow-functional-indexes-td2059587.html


-- 
Stuart Bishop 
http://www.stuartbishop.net/


-- 
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 #7663: is not a bug but...

[ilfb]

The following bug has been logged on the website:

Bug reference:  7663
Logged by:  Ignacio Ferreira
Email address:  i...@yahoo.com
PostgreSQL version: 9.1.0
Operating system:   centos
Description:

Excuse me for my English.
I tried to download the PDF version of documentation, but when I open the
file acrobat reader say that the file is corrupted. Can you send me an
e-mail with the correct file please.



-- 
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 #7657: Create Table doesn't create columns

[Matthew Kuss]

Thanks everyone for the help. I have it working now. Unfortunately I'm not
sure why it wasn't working before or what was causing the problem. I spent
all day taking piece after piece out of my "logging package" (Depesz - this
is a program that I wrote and modified over the past few years) until I
found the part that was causing the error. I was still unable to figure out
why this particular part wasn't working so I just replaced it with some
other code I had for a different project that was based off of this problem
code. Long story short, it's working now, but I'm not sure why it's working
this way but not the other way. Hopefully sometime soon I'll have time to go
back and figure out what happened. If I do, I'll let ya'll know!

Thanks again for the help!
Matt

-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us] 
Sent: Wednesday, November 14, 2012 2:03 PM
To: Matthew Kuss
Cc: dep...@depesz.com; pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #7657: Create Table doesn't create columns

"Matthew Kuss"  writes:
> Depesz -
> I'm fairly sure it's not a problem with something I'm doing wrong because
I've used the same code before. It has to be something wrong on the DB side.
But just to entertain you I did as you requested:

> RigMinder_NewDBTest02=# \d test
> Table "public.test"
>  Column | Type | Modifiers
> +--+---


> RigMinder_NewDBTest02=#

> Before I ran this I created a table using the following:

> create table "test" ("column1" text, "column2" float);

Hm ... maybe that's creating the table somewhere other than schema public?
What have you got search_path set to?  Try
\dt *.test
to see if there's more than one table named "test".

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 #7659: LDAP auth does not search the subtree

[kevin]

The following bug has been logged on the website:

Bug reference:  7659
Logged by:  Kevin Smith
Email address:  ke...@rootsmith.ca
PostgreSQL version: 9.2.1
Operating system:   CentOS5
Description:

I have the following in my pg_hba.conf file:

host all +ldap 127.0.0.1/32 ldap ldapserver= ldapport=389
ldapbasedb="" ldapbinddn="" ldapbindpasswd=
ldapsearchattribute=

If I try to connect from the localhost with a valid ldap account, it fails.
Note that the  is located in objects, one level deeper than the
 given.

The error in the log is as follows:

could not search LDAP for filter "(=)" on server
"": error code 1

However, when I do the following on the command line, it works:

ldapsearch -x -L -b "" -D "" -w  -H
ldap://:389 "(=my_user)"

When I change the configuration in pg_hba.conf so that the ldapbasedn is
exactly on the same level as where the user resides, it works perfectly.

The documentation states "The search will be performed over the subtree at
ldapbasedn" but this does not appear to be the case from my testing. The
scope appears to be defaulting to be just searching the base.



-- 
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 #7660: Installation problem

[dominique-doisne]

The following bug has been logged on the website:

Bug reference:  7660
Logged by:  Dominique DOISNE
Email address:  dominique-doi...@idoine-formation.com
PostgreSQL version: 9.2.1
Operating system:   Windows 7
Description:

- After installation directory c :/ "Program Files/PostgreSQL/9.2/data" is
empty.
-  Absence of the configuration file "postgresql.conf.", then message
"Server does not listen"













-- 
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 #7664: Program using libpq and ecpglib can not output native language

[Tom Lane]

che...@cn.fujitsu.com writes:
> I knows reason. The default locale of a program is "C" in Linux,regardless
> the Environment Variables.
> if add the following line in my program,everything is OK.

> setlocale(LC_ALL, "");

> But I found no document tell users should do so.And I think it's not a easy
> way.Can libpq and ecpglib do it for users?

No, it would most certainly be inappropriate for a library to do that.
setlocale could completely break a program that wasn't expecting it.
The effects would be global across the whole process, not confined to
the library.

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