Re: [BUGS] BUG #8455: spanish pgadmin3.mo
On Thu, 2013-09-26 at 21:18 -0400, Bruce Momjian wrote: On Mon, Sep 16, 2013 at 08:40:57AM +, j.rom...@salsa.es wrote: The following bug has been logged on the website: Bug reference: 8455 Logged by: Jesus Romero Email address: j.rom...@salsa.es PostgreSQL version: 9.1.9 Operating system: Ubuntu server 12.04 Description: The actual version of pgadmin3 1.18 includes a wrong file pgadmin3.mo for the spanish languaje. The file included is catalan languaje not the spanish one. You should report this to the pgadmin developers on one of their email lists: http://www.pgadmin.org/support/list.php Actually, this has already been fixed. My fault, my fix :) -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.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 in Prepared statement with DELETE RETURNING and rule on view
On Tue, 2013-05-28 at 12:41 +0530, Amit Kapila wrote: On Tuesday, May 28, 2013 12:39 AM Brice André wrote: Dear all, I found what I really think is a bug in the postgresql 8.4. I have an sql database structure in which a real table has a column that is used to mark the entries as deleted without really deleting them. Then, I have a view that is hiding this to the users, with proper rules that perform real actions on the table. So, a ON DELETE rule on this view is performing an UPDATE which marks the rows as delete without deleting them. The view is hiding the rows tagged as deleted. This code is working from several years and I have a web-service that performs several actions on top of this database. Those actions include a DELETE ... RETURNING ... command on the view. This web-service was implemented by a php script that did not use any prepared statement, and everything was working properly. I had performance issue with this solution and I decided to rewrite the service in C++, and to use prepared statements. The SQL commands are exactly the same, but they are now executed from a C++ application using libpq, and they use prepared statements. I had tried in latest 9.3 code with psql using prepared statements and it worked fine, please see result below. I shall check your libpq application code as well, but in the mean time can you please verify whether the below works for you on 8.4 (I don't have 8.4 setup). It does work with psql and pgAdmin. The issue is with PQprepare, and PQexecPrepared. So yeah, you need to look at the application code. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.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 #7506: Windows 64 bit PGAdmin 1.14.3 plpgsql default parameter value not appearing
On Sat, 2012-08-25 at 00:56 +, crisp...@gmail.com wrote: The following bug has been logged on the website: Bug reference: 7506 Logged by: Cris Pond Email address: crisp...@gmail.com PostgreSQL version: 9.1.5 Operating system: Windows 64 bit Description: Sorry, I'm having trouble posting a bug report to the pgAdmin site. How so? you just need to send an email to pgadmin-support mailing list (http://archives.postgresql.org/pgadmin-support/). Please forward this on: It looks like this bug has come back in pgAdmin 1.14.3 for Windows 64bit: http://code.pgadmin.org/trac/ticket/79 If you do the following: -- CREATE OR REPLACE FUNCTION demo(level integer DEFAULT 0) RETURNS integer language 'plpgsql' AS $$ BEGIN return (level); END; $$; select demo(); -No error -- The default parameter functions correctly. The code showing in pgadmin, however, is missing the default: - drop function if exists demo(int); --Copied from pgAdmin CREATE OR REPLACE FUNCTION demo(level integer) RETURNS integer AS $BODY$ BEGIN return (level); END; $BODY$ LANGUAGE plpgsql VOLATILE COST 100; select demo(); -Error -- I'm pretty sure pg_proc.proargdefaults contains the correct information and that pgadmin is just not interpreting it. I tried executing the code on postgresql 8.4.3 and 9.1.5, and the field looked basically the same, but pgAdmin 1.10 is displaying correctly and pgAdmin 1.14.3 is not. This has been fixed in 1.16 in june, so you can have a fixed binary with 1.16 beta 4. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.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] Error on pg_settings.bytea_output for pg9.1
On Tue, 2012-07-31 at 14:06 +0800, Craig Ringer wrote: On 07/31/2012 01:50 PM, Guillaume Lelarge wrote: Check the PgAdmin-III preferences; there may be an option to control its preferred bytea format. There's no option to control this. Thanks for confirming that. Is it really best for PgAdmin-III to have a different default than Pg its self? Well, we didn't until we had an issue to get informations from the tgargs column of the pg_trigger catalog. I don't remember the details right now, and I still didn't check how psql works with this, so I may be wrong. The only way I could find to fix the issue was to set bytea_output to escape. It probably is specific to pgAdmin. If we can't fix this another way, we can have a workaround. We only need this setting for pgAdmin's browser. Not the query tool. It would be a nice and quick workaround. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.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] Error on pg_settings.bytea_output for pg9.1
On Tue, 2012-07-31 at 10:19 +0800, Craig Ringer wrote: On 07/30/2012 11:49 AM, Emcisc (JinWei) Zhao wrote: 5.Run the SQL query: SELECT setting FROM pg_settings WHERE name = 'bytea_output'; in pgAdmin3. It will show you the value 'escape'. 6.Run the client application 'psql' to connect to the same DB server and database with the same user account. And in psql interactive terminal, run the same SQL: SELECT setting FROM pg_settings WHERE name = 'bytea_output'; . It will show you the value 'hex', NOT the previous value 'escape'. 7.That means, the same environment, the same SQL query, but different output. And I don't touch the file postgresql.conf any more ever before. Is this a bug of pgAdmin3? I don't know if it's a bug as such, but it's certainly a curious decision if what you describe is the intended behaviour. It sounds like PgAdmin-III might be sending a SET bytea_output = 'escape' query during connection setup. Yes, pgAdmin sets bytea_output, and also DateStyle, and client_min_messages, right after the connection is done. bytea_output is a per-session parameter. Each session (connection) to PostgreSQL can have a different value, and it can be changed within the session. Check the PgAdmin-III preferences; there may be an option to control its preferred bytea format. It may also be worth turning on log_statement = 'all' in postgresql.conf, starting PgAdmin-III, then looking at the PostgreSQL logs to see if PgAdmin-III is in fact sending a `SET bytea_output` command. There's no option to control this. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.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 #6720: Its often disconnecting
On Fri, 2012-07-06 at 08:12 +0800, Craig Ringer wrote: On 07/06/2012 03:57 AM, balaj...@gmail.com wrote: The following bug has been logged on the website: Bug reference: 6720 Logged by: balaji Email address: balaj...@gmail.com PostgreSQL version: Unsupported/Unknown Operating system: Windows Xp Description: Error is PGADMIN 111 has encountered a problem and need to close.we are sorry for the inconvenience.Please advise me. PgAdmin-III is crashing. With the amount of information you have provided it is impossible to guess why. You haven't said what you're doing when it crashes, whether you can make it crash at the same point every time, etc. Honestly, for PgAdmin you're probably better off seeking help on their mailing list: http://www.pgadmin.org/support/list.php as I'm not sure how many of the PgAdmin folks read pgsql-bugs. I do, and I think Dave too. But pgadmin bug reports should be sent to pgadmin-hackers or pgadmin-support lists. Definitely not here, as you said :) -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.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 #6543: pgadmin III - Error defining filter.
On Mon, 2012-03-19 at 17:47 +, kebe.1...@gmail.com wrote: The following bug has been logged on the website: Bug reference: 6543 Logged by: Cleberson Email address: kebe.1...@gmail.com PostgreSQL version: 9.1.3 Operating system: Windows 7 Description: When you create a column name with uppercase ( idCustomer ) you can´t define a filter to thi col, because internaly de pgadmin converts the name to ( idcustomer ) and show an error that the column does not exist. pgAdmin doesn't. PostgreSQL does. If you want to filter, you need to put your column between double quotes. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.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 #6527: Error in COPY documentation syntax
On Mon, 2012-03-12 at 19:34 +, samuel.gilb...@ec.gc.ca wrote: The following bug has been logged on the website: Bug reference: 6527 Logged by: Samuel Gilbert Email address: samuel.gilb...@ec.gc.ca PostgreSQL version: 9.0.4 Operating system: Linux Description: There is an error in the syntax of the COPY statement in the documentation for versions 9.0.x and 9.1.x. I tested on 9.0.4 and 9.1.3. According to the documentation, given the table exists and is compatible with the CSV file, the following statement should work : COPY improve_station FROM '/local/improve.csv' FORMAT CSV HEADER TRUE; No, it shouldn't work. You forgot parentheses, and commas. This should work: COPY improve_station FROM '/local/improve.csv' (FORMAT CSV, HEADER TRUE); However, it doesn't work. Instead I get the following error : ERROR: syntax error at or near FORMAT LINE 1: ...ns FROM '/local/improve.csv' FORMAT CSV... ^ After trying a few trials and errors, I managed to find that ommiting FORMAT gave me another error instead : COPY improve_stations FROM '/local/improve.csv' CSV HEADER TRUE; ERROR: syntax error at or near TRUE LINE 1: ...M '/local/improve.csv' CSV HEADER TRUE; ^ Removing the boolean value (TRUE) actually works. This means that there are at least two errors in the syntax specification in the documentation. Instead of FORMAT format_name, it should be [ TEXT | CSV | BINARY ] and HEADER [ boolean ] should be [ HEADER ]. No error, and no bug. The documentation says (even if it's hard to see) that you need parentheses and commas. The examples show it too. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.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 #6478: Foreign tables not displayed
On Mon, 20 Feb 2012 16:32:27 +, ro...@chmela.sk wrote:
The following bug has been logged on the website:
Bug reference: 6478
Logged by: Roman Chmela
Email address: ro...@chmela.sk
PostgreSQL version: 9.1.2
Operating system: 1) Windows 7 pro, 2) Ubuntu
Description:
Hello
I have setup successfully foreign table, fully functional, retrieving
data
from external csv file:
create extension file_fdw;
CREATE SERVER file_server FOREIGN DATA WRAPPER file_fdw;
CREATE FOREIGN TABLE my_names (
name text,
surname text
) SERVER file_server
OPTIONS (format 'text', filename 'c:\xxx\my_names.csv', delimiter ';',
null
'');
-
Problem:
-
- this table is not listed among tables (using pgadmin)
---
Possible solution?
---
CREATE OR REPLACE VIEW pg_tables AS
SELECT n.nspname AS schemaname, c.relname AS tablename,
pg_get_userbyid(c.relowner) AS tableowner, t.spcname AS tablespace,
c.relhasindex AS hasindexes, c.relhasrules AS hasrules, c.relhastriggers
AS
hastriggers
FROM pg_class c
LEFT JOIN pg_namespace n ON n.oid = c.relnamespace
LEFT JOIN pg_tablespace t ON t.oid = c.reltablespace
--WHERE c.relkind = 'r'::char;
WHERE c.relkind in ('r'::char,'f'::char);
Foreign tables have their own node. This node is not displayed by default.
You need to go the preferences dialog, select the Browser tab, and check
the Foreign tables checkbox. And reconnect to your server. That should
display a new node with all foreign tables.
BTW, if you find bugs or have issues with pgadmin, you shouldn't send them
here. Use the pgadmin-support mailing list instead.
--
Guillaume
http://www.postgresql.fr
http://dalibo.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] Syntax got translated
On Mon, 20 Feb 2012 14:15:34 -0300, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Susanne Ebrecht's message of sáb feb 18 18:11:54 -0300
2012:
Output in German:
i | integer | not null Vorgabewert nextval('t_i_seq'::regclass)
Output in French:
i | integer | non NULL Par défaut, nextval('t_i_seq'::regclass)
Output in Spanish:
i | integer | not null valor por omisión
nextval('t_i_seq'::regclass)
I think that the constraint keyword DEFAULT should not be translated
here.
In my eyes in all cases it should output:
i | integer | not null default nextval('t_i_seq'::regclass)
I'm not clear on this. I translated it because it seemed sensible, but
I remember stopping for a minute to consider it. Maybe if more people
thinks it should not be translated, we could remove the translatability
marker from DEFAULT and other stuff like NOT NULL. I'mnot sure
however. Just removing the translations from the existing catalogs is
not enough, because future versions will just put them back.
I don't see why the modifiers shouldn't be translatable. It's not as if
they were intended to be copied and pasted in a query. They are here to
help the user understand the different modifiers in each column.
-1 to get rid of the translations.
--
Guillaume
http://www.postgresql.fr
http://dalibo.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] Syntax got translated
On Mon, 20 Feb 2012 21:47:49 +0100, Susanne Ebrecht susa...@2ndquadrant.com wrote: Am 20.02.2012 21:22, schrieb Guillaume Lelarge: I don't see why the modifiers shouldn't be translatable. It's not as if they were intended to be copied and pasted in a query. They are here to help the user understand the different modifiers in each column. Of course they are intended to get copied and pasted. In support you often ask for output from \d tablename. And when I look to the languages that I never learned, especially when I look into Turkish - I would read NULL and not would estimate column is not NULL. Default and not null are keywords - they are valid sql syntax. They are constraint definitions. When I output the table definition I want the constraint definition - I don't want to translate it back to english to understand - a default is meant. If that's so, nothing should be translatable in psql. If you do \d, the second column is the relation type. I guess seeing vue instead of view won't help you, so we need to stop translating this. The table's title shouldn't be translatable too. Etc. If you want the english way, you already can do this. You just need to ask your customer to use LANG=C psql instead of psql. -- Guillaume http://www.postgresql.fr http://dalibo.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] Syntax got translated
On Mon, 20 Feb 2012 15:55:54 -0500, Tom Lane t...@sss.pgh.pa.us wrote: Guillaume Lelarge guilla...@lelarge.info writes: On Mon, 20 Feb 2012 14:15:34 -0300, Alvaro Herrera alvhe...@commandprompt.com wrote: Excerpts from Susanne Ebrecht's message of sáb feb 18 18:11:54 -0300 I think that the constraint keyword DEFAULT should not be translated here. I don't see why the modifiers shouldn't be translatable. It's not as if they were intended to be copied and pasted in a query. They are here to help the user understand the different modifiers in each column. -1 to get rid of the translations. It seems to boil down to whether you think the Modifiers column contains SQL, or a textual description of the column's properties. I could go either way on that, but I notice that the existing code is in the habit of truncating the default expression at 128 characters. If we want to decide that we're printing real, copy-and-pastable SQL, that seems like a bad idea. On the other hand, if we're printing informational text, it's not an unreasonable thing. My first move was that truncating to 128 characters was bad idea. But in a terminal, you have a limited number of columns, so it would make sense. And, to me, it's a textual description. Not SQL. BTW, if it was SQL, when I do \d tablename, I should get the complete SQL query to create the table, not a description of the table definition. So, yeah, sure, the Modifiers column doesn't contain SQL, it's a description. -- Guillaume http://www.postgresql.fr http://dalibo.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] Syntax got translated
On Mon, 20 Feb 2012 22:14:32 +0100, Susanne Ebrecht susa...@2ndquadrant.com wrote: Am 20.02.2012 21:55, schrieb Tom Lane: It seems to boil down to whether you think the Modifiers column contains SQL, or a textual description of the column's properties. I could go either way on that, but I notice that the existing code is in the habit of truncating the default expression at 128 characters. If we want to decide that we're printing real, copy-and-pastable SQL, that seems like a bad idea. On the other hand, if we're printing informational text, it's not an unreasonable thing. regards, tom lane We might also have a culture difference here. I discovered it during a demonstration in my training class. The whole class laughed - when they read Vorgabewert instead of Default. Maybe Germans aren't used to have a translation here - Maybe French folk is used to have a translation here. French folks are used to have translations everywhere. And if they don't, they scream :) I don't say it's a good thing :) -- Guillaume http://www.postgresql.fr http://dalibo.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] Syntax got translated
On Mon, 20 Feb 2012 22:49:16 +0100, Susanne Ebrecht susa...@2ndquadrant.com wrote: Am 20.02.2012 22:19, schrieb Guillaume Lelarge: French folks are used to have translations everywhere. And if they don't, they scream :) I don't say it's a good thing :) That is why I expected a culture difference here. I know that in French all get translated to French. That is the French culture - the French language - neither good nor bad. It is like it is. There are other languages that work similar to French. Languages like German, Dutch and others just work different. Germans often just take the English word and use it - and after a while you can find the English word in German thesaurus using German grammar. When the word made it into our thesaurus - then the English word finally got adopted as German word. Honestly, the problem Germans have with it is - thinking to beginners - when they read Default they know that there is a default constraint on it. When they read one of the translations for default - they don't know what is going on. You really need to translate to English to understand that it is a default constraint. Germans are confused from such kind of translations. It is more confusing for them as it will help them. I don't know if it is possible - but could it get split by language here. Translate in French but not in German or so. Sure, just don't translate it in the german .po file. Or, better, use the same string. -- Guillaume http://www.postgresql.fr http://dalibo.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 #6406: Included pgAdmin does not have .sql file extension mapped
On Mon, 2012-01-23 at 01:08 +, a...@arencambre.com wrote: The following bug has been logged on the website: Bug reference: 6406 Logged by: Aren Cambre Email address: a...@arencambre.com PostgreSQL version: 9.1.2 Operating system: Windows 7 x64 Description: When I install Postgres, the included pgAdmin III is not set up correctly: the installer does not associate .sql file extensions with pgAdmin III, so when I double-click on a .sql file, or even right-click on it and select Open with, pgAdmin III doesn't even show as an option. I checked with pgAdmin III developers, and with them, I confirmed that the pgAdmin III installer, as downloaded from their own site, indeed sets up file extensions correctly. Guillaume Lelarge of pgAdmin dev team suspects it may be a problem with how you've bundled pgAdmin III with Postgres. And I also said you should complain to the packager which is EnterpriseDB, not the PostgreSQL developers. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com PostgreSQL Sessions #3: http://www.postgresql-sessions.org -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
