Re: [BUGS] BUG in pg_autovacuum - with patch
Karl Denninger wrote: I have a process which does backups by mounting a disk into a RAID array, allowing it to sync, then it must stop the database before detaching it so as to insure that the DBMS is consistent on the backup disk. Once detached, Postgres must be restarted, of course.. This process is MUCH faster than dumping the disks to tape and results in a bootable backup volume - the latter is of great value for disaster recovery! The problem is that if pg_autovacuum exits and then is relaunched, it doesn't remember any of it's state information from when it last exited. So if you are stopping and starting autovacuum one a day, it will be less effective. If you have some very active tables that autovacuum will vacuum several times a day then I can still see it's usefullness, but it's never going to vacuum a table that doesn't have enough activity to cause a vacuum in one day. Anyway, if pg_autovacuum is causing problems for cron I'm sure we would still benefit from this patch. However, while I claim no expertise related to detaching from the console, I will say that I copied the code detach code directly from postgresql itself, so I would have thought it was OK. Can someone more informed than I take a look at this patch? Thanks, Matthew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] BUG in pg_autovacuum - with patch
On Sat, Apr 02, 2005 at 12:16:00PM -0500, Matthew T. O'Connor wrote: > Karl Denninger wrote: > > >I have a process which does backups by mounting a disk into a RAID array, > >allowing it to sync, then it must stop the database before detaching it so > >as to insure that the DBMS is consistent on the backup disk. > > > >Once detached, Postgres must be restarted, of course.. > > > >This process is MUCH faster than dumping the disks to tape and results in a > >bootable backup volume - the latter is of great value for disaster recovery! > > > > > > The problem is that if pg_autovacuum exits and then is relaunched, it > doesn't remember any of it's state information from when it last > exited. So if you are stopping and starting autovacuum one a day, it > will be less effective. If you have some very active tables that > autovacuum will vacuum several times a day then I can still see it's > usefullness, but it's never going to vacuum a table that doesn't have > enough activity to cause a vacuum in one day. > > Anyway, if pg_autovacuum is causing problems for cron I'm sure we would > still benefit from this patch. However, while I claim no expertise > related to detaching from the console, I will say that I copied the code > detach code directly from postgresql itself, so I would have thought it > was OK. Can someone more informed than I take a look at this patch? > > Thanks, > > Matthew You left out the closeout of the stdio streams from the Postgresql code you copied. :-> -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant & Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://www.spamcuda.net SPAM FREE mailboxes - FREE FOR A LIMITED TIME! http://genesis3.blogspot.comMusings Of A Sentient Mind ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] On line manual pages need easy access to TOC
Hi, It's a real pain to have to go to the bottom of the on-line manual pages to get back to the table of contents (I seem to want to do this all the time.) A link at the top would be nice. You could either add a "Home" link like at the bottom, or simply make the manual version number hot. Regards, Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[BUGS] BUG #1575: plpgsql
The following bug has been logged online: Bug reference: 1575 Logged by: rajkumar Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.1 Operating system: linux and windows Description:plpgsql Details: hello, we have a postgres in windows and linux operating systems, then the problem is in plpgsql functions, which is i created a function with exception handling in postgres 8.0.1 (windows operating system) which handle the exceptions very well, but i created the same function in (postgres 8.0.1)linux operating system, it gives a syntax error near the exception, so please tell me, how can i resolve this problem. with regards, rajkumar ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #1576: Function UPPER does not give back the awaited results
The following bug has been logged online:
Bug reference: 1576
Logged by: Sergio Luis Sánchez
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.3 and 8.0.1
Operating system: linux (7.4.3) and WinXP (8.0.1)
Description:Function UPPER does not give back the awaited results
Details:
Hi.
I'm from Spain, and I am using a PostgreSQL as database system. Sorry for my
English.
I launch a select with the upper function to retrieve a text in capital
letters. When I launch the function to text with accents (Usual in Spanish
language), I get the marked words in lowercase, and it's wrong.
To test it I launh this query:
select upper('aeiouáéíóúàèìòù');
And the result was: "AEIOUáéíóúàèìòù", when it must be
"AEIOUÁÉÍÓÚÀÈÌÒÙ".
I try this function with UNICODE and LATIN1 encodings, and I retrieve same
result.
I reproduce the error in this two versions of Postgres:
- PostgreSQL 7.4.3 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.3
20030502 (Red Hat Linux 3.2.3-24)
- PostgreSQL 8.0.1 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.4.2
(mingw-special)
NOTE: lower function fails too with marked words.
Thanks in advance
---(end of broadcast)---
TIP 3: 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
[BUGS] windows installation
hi. this is not really an installation issue, but i read the instruction atop of the list, so here we are. ok. i succesfully installed postgresql 8 on my windows xp sp2 machine, few weeks ago. i am a newbie to sql generally, as well as to postrges i configured my server to run on localhost, everything was fine. i need to mention that the machine is part of a active directory network, corporate 350+ machines, policies, etc. the thing is that i haven't started postrges for about a week, during wich time i have not made changes to the machine, nor installed any software that could affect the performance/security/policy allready running on my machine, a p4 -3,2 HT, 512 DDR, 80 GBsata, a rather nice machine, otherwise. when i tried to connect to the database, i received an error, that i cannot connect to the database as a superuser. i have configured .\postgre to run automatically on system start, and worked just fine. i only modifyed the tmplate to logon to a custom test database, but i worked fine everytime before the pause i already mentioned. after varoius error messages, error log, etc i discovered the service to have been disabled, and set for deletion. as i could not modify it's state through "normal" procedure - mmc console, i regedit-modifyed the service's state to autimatic from disabled. the thing is, that when i attempt to start, i get an error message that the service could not start because it is eighter disabled, or has no devices attached to it. in the service's propeties box, at the start parameters box - blank. if i need start parameters can u please give me some feedback on this regard, or if there's something else, please let me know. i checked with the network admin, and there is no change lately in the pilocies. i guess it's useful to know that there is a concurrent-login prohibiton policy, and event log says Event Type: Failure Audit Event Source: Security Event Category: Logon/Logoff Event ID: 534 Date: 31.03.2005 Time: 15:44:09 User: NT AUTHORITY\SYSTEM Computer: x Description: Logon Failure: Reason: The user has not been granted the requested logon type at this machine User Name: concurrent_logins Domain: xx Logon Type: 3 Logon Process: Kerberos Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 Workstation Name: - For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. help anyone? best regards, raymond -- listen. see. believe. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #1574: plpgsql
The following bug has been logged online: Bug reference: 1574 Logged by: rajkumar Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.1 Operating system: linux and windows Description:plpgsql Details: hello, we have a postgres in windows and linux operating systems, then the problem is in plpgsql functions, which is i created a function with exception handling in postgres 8.0.1 (windows operating system) which handle the exceptions very well, but i created the same function in (postgres 8.0.1)linux operating system, it gives a syntax error near the exception, so please tell me, how can i resolve this problem. with regards, rajkumar ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] Help
Hi, I have installed PostgreSQL 8.0.1 on Solaris 9. I am porting my database from Oracle 9i to PostgreSQL. I am using PL/pgSQL language. In Oracle we can get error message from "SQLERRM" keyword and inserting it into table. How can I get error message/code in PostgreSQL after an EXCEPTION or RAISE EXCEPTION occurs in EXCEPTION block?? Pls help me or send me some example. Thanks Dinesh Pandey
[BUGS] BUG #1570: Double quotes in all field/table names must be optional!
The following bug has been logged online:
Bug reference: 1570
Logged by: Christopher Brian Jurado
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0
Operating system: Windows 2000
Description:Double quotes in all field/table names must be optional!
Details:
The double quote(") for field/table names doesn't seem to be optional when
using it in queries.
I used pgAdmin under verion 8.0 to query any field on any table. A message
says the relation does not exist. If I double-quote the field names and
table names, then it works. Isn't it a very big burden to keep typing double
quotes?
I tried searching through the postgresql.conf file but nothing is there to
control this behavior.
In the documentation, they show samples without double quotes but it
actually doesn't work when you try it.
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
[BUGS] FW: Help
From: Dinesh Pandey [mailto:[EMAIL PROTECTED] Sent: Thursday, March 31, 2005 2:45 PMTo: pgsql-bugs@postgresql.orgSubject: HelpImportance: High Hi, I have installed PostgreSQL 8.0.1 on Solaris 9. I am porting my database from Oracle 9i to PostgreSQL. I am using PL/pgSQL language. In Oracle we can get error message from "SQLERRM" keyword and inserting it into table. How can I get error message/code in PostgreSQL after an EXCEPTION or RAISE EXCEPTION occurs in EXCEPTION block?? Pls help me or send me some example. Thanks Dinesh Pandey CREATE OR REPLACE FUNCTION DOES_NODE_HAVE_RULE (IN_SENTRYID_ID IN NUMBER ,IN_NODE_ID IN NUMBER ,IN_DEVICEID IN NUMBER ,IN_ACTION IN VARCHAR2 ) RETURN BOOLEAN IS does NUMBER(2) := 0; mesg VARCHAR2(500) := 'Does rule exist failed for sentry: '||in_sentryid_id||', node: '||in_node_id||'.'; c_context VARCHAR2(50) := 'DOES NODE HAVE RULE'; c_program VARCHAR2(100) := 'RULE_CONTROL.DOES_NODE_HAVE_RULE'; v_sql VARCHAR2(1000);BEGIN v_sql := 'SELECT COUNT(*) FROM PORTAL_'||in_action||'_NODE_RULE WHERE sentryid_id = '||in_sentryid_id|| ' AND node_id = '||in_node_id||' AND device_id ='||in_deviceid; EXECUTE IMMEDIATE v_sql INTO does; IF does > 0 THEN RETURN TRUE; ELSIF does = 0 THEN RETURN FALSE; END IF; EXCEPTION WHEN OTHERS THEN DATAMAN.log_error(c_program, c_context, 1, 'PACKAGE', 'OTHERS: '||mesg, SQLERRM); RAISE_APPLICATION_ERROR(-2,SUBSTR(SQLERRM,1,250)); END does_node_have_rule;/SHOW ERROR
Re: [BUGS] BUG #1567: can't hide password with pg_autovacuum
Le Tuesday 29 March 2005 00:40, vous avez écrit : > The typical way to do this is to use .pgpass in the user's home > directory. Does that help? Yes it help, but: - please notice the issue about ps into the README - the .pgpass doesn't work on my configuration: [EMAIL PROTECTED] pgsql]$ pg_autovacuum [2005-03-29 04:47:32 CEST] ERROR: Failed connection to database template1 with error: fe_sendauth: no password supplied . [2005-03-29 04:47:32 CEST] ERROR: Failed connection to database template1 with error: fe_sendauth: no password supplied . [2005-03-29 04:47:32 CEST] ERROR: Cannot connect to template1, exiting. When permission are bad on .pgpass (other than 600), it complain, but failed to connect on my server. Notice I have seting up access to 'password' to all connection in my pg_hba.conf. psql... work fine and the password in .pgpass is ok. Maybe I will workaround by setting postgres user access as 'trust' for local connection only, but I have to reread the doc before :). > > --- > > Olivier Thauvin wrote: > > The following bug has been logged online: > > > > Bug reference: 1567 > > Logged by: Olivier Thauvin > > Email address: [EMAIL PROTECTED] > > PostgreSQL version: 8.0.1 > > Operating system: Linux (Mandrake cooker) > > Description:can't hide password with pg_autovacuum > > Details: > > > > I found an security with pg_autovacuum :( > > After looking the README and --help, it seems there is no way to start it > > with a configuration file. > > > > This is not a problem except when the database is password protected, so > > you have to use -P option to get it started (no prompt excpet I missed > > something). > > > > The potential issue come from ps, the password is show in clear: > > > > nanardon 28664 0.4 0.0 3644 1384 ?Ss 04:05 0:00 > > pg_autovacuum -D -s rpm2sql -PXX > > > > XX is my password in clear (hidden here of course). > > As you can see, there is enought information here for someone having an > > account on the host to connect to DB with admin privileges on the DB (not > > as postgres user of course, but only the owner of the db can vacuum). > > > > Solution: > > - change the command line after start like some ftp client does > > - having the possiblility to read password from a file > > - taking password from envirronment variable (AUTOVACUUM_PASS=pass > > pg_autovacuum...) > > > > If I have any time, I will try to provide a patch, but my knowledge in C > > are too poor to ensure quality :( > > > > ---(end of broadcast)--- > > TIP 9: the planner will ignore your desire to choose an index scan if > > your joining column's datatypes do not match pgpNreZhNZ2wB.pgp Description: PGP signature
[BUGS] BUG #1573: plpgsql
The following bug has been logged online: Bug reference: 1573 Logged by: rajkumar Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.1 Operating system: linux and windows Description:plpgsql Details: hello, we have a postgres in windows and linux operating systems, then the problem is in plpgsql functions, which is i created a function with exception handling in postgres 8.0.1 (windows operating system) which handle the exceptions very well, but i created the same function in (postgres 8.0.1)linux operating system, it gives a syntax error near the exception, so please tell me, how can i resolve this problem. with regards, rajkumar ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] BUG #1572: plpgsql in linux os
The following bug has been logged online: Bug reference: 1572 Logged by: rajkumar Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.1 Operating system: linux Description:plpgsql in linux os Details: hello, we have a postgres in windows and linux operating systems, then the problem is in plpgsql functions, which is i created a function with exception handling in postgres 8.0.1 (windows operating system) which handle the exceptions very well, but i created the same function in (postgres 8.0.1)linux operating system, it gives a syntax error near the exception, so please tell me, how can i resolve this problem. with regards, rajkumar ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #1569: Threads don't see ecpg default connection
The following bug has been logged online:
Bug reference: 1569
Logged by: Gavin Scott
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.1
Operating system: Fedora Core 3
Description:Threads don't see ecpg default connection
Details:
When using postgresql 8.0 compiled with --enable-thread-safety, new threads
no longer see the default ecpg connection. That was not the case in 7.4.x
compiled with or without --enable-thread-safety.
TEST CASE
The program at the end of this mail sets up a database table named
"dbthreadtest" in the default database. It then spawns 5 threads which each
do a select from that table using the default connection.
If the program is saved as dbthreadtest.pgc, compile with:
ecpg -t -o dbthreadtest.c dbthreadtest.pgc
gcc -Wall -o dbthreadtest dbthreadtest.c -lecpg -lpthread
Results under 7.4.x / 8.0 without --enable-thread-safety:
[EMAIL PROTECTED] protocol_lib]$ psql --version
psql (PostgreSQL) 7.4.7
contains support for command-line editing
[EMAIL PROTECTED] protocol_lib]$ ./dbthreadtest
got id = 1
got id = 1
got id = 1
got id = 1
got id = 1
Results under 8.0 with --enable-thread-safety:
[EMAIL PROTECTED] protocol_lib]$ psql --version
psql (PostgreSQL) 8.0.1
contains support for command-line editing
[EMAIL PROTECTED] protocol_lib]$ ./dbthreadtest
'No such connection NULL in line 76.', sqlcode = -220 select id
TEST PROGRAM
/* -*-C-*- */
#include
#include
#define CHECK_SQL(fmt, args...) \
do \
{ \
if (sqlca.sqlcode != ECPG_NO_ERROR) \
{ \
fprintf (stderr, "'%s', sqlcode = %ld " fmt "\n", \
sqlca.sqlerrm.sqlerrmc, \
sqlca.sqlcode, ## args); \
exit (1); \
} \
} \
while (0)
#define FATAL(fmt, args...) \
do \
{ \
fprintf (stderr, fmt "\n", ## args); \
exit (1); \
} \
while (0)
pthread_mutex_t global_lock;
pthread_t global_threads[5];
void
setup_db ()
{
exec sql begin declare section;
const char *_user;
exec sql end declare section;
pthread_mutex_lock (&global_lock);
_user = getenv ("LOGNAME");
exec sql connect to :_user;
CHECK_SQL ("connect");
exec sql create table dbthreadtest (id int);
CHECK_SQL ("create dbthreadtest");
exec sql insert into dbthreadtest (id) values (1);
CHECK_SQL ("insert 1");
pthread_mutex_unlock (&global_lock);
}
void
teardown_db ()
{
pthread_mutex_lock (&global_lock);
exec sql drop table dbthreadtest;
CHECK_SQL ("drop dbthreadtest");
exec sql disconnect;
CHECK_SQL ("disconnect");
pthread_mutex_unlock (&global_lock);
}
void *query_db (void *ignorep)
{
exec sql begin declare section;
int _id;
exec sql end declare section;
pthread_mutex_lock (&global_lock);
exec sql select id into :_id from dbthreadtest;
CHECK_SQL ("select id");
fprintf (stdout, "got id = %d\n", _id);
pthread_mutex_unlock (&global_lock);
return NULL;
}
int
main ()
{
int i;
pthread_mutex_init (&global_lock, NULL);
setup_db ();
for (i = 0; i < sizeof (global_threads) / sizeof (global_threads[0]);
++i)
{
if (pthread_create (&global_threads[i], NULL, query_db, NULL))
FATAL ("pthread_create %d failed", i);
}
for (i = 0; i < sizeof (global_threads) / sizeof (global_threads[0]);
++i)
{
if (pthread_join (global_threads[i], NULL))
FATAL ("pthread_join %d failed", i);
}
teardown_db ();
return 0;
}
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
[BUGS] error pgsql
can u'll help me ? i use debian woody 3 in debian install postgresql can't find zlib how to activity zlib on debian ? and on debian can't use gmake i always use make and make install and pgsql can't running thank's all ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #1547: CREATE TYPE AS error
I re-installed postgresql as a service and CREATE TYPE AS works. So I then re-installed postgresql as a program (as I had originally done) and CREATE TYPE AS doesn't work. Perhaps you could check this on your system. John Smith -- From: Michael Fuhr <[EMAIL PROTECTED]> Reply-To: pgsql-bugs@postgresql.org To: John Smith <[EMAIL PROTECTED]> CC: pgsql-bugs@postgresql.org Subject: Re: [BUGS] BUG #1547: CREATE TYPE AS error Date: Tue, 22 Mar 2005 20:07:13 -0700 On Tue, Mar 22, 2005 at 11:05:46PM +, John Smith wrote: > In my haste to write the email I didn't notice the spelling mistake. > However in postgres I did spell > CREATE coreectly. I am using the Windows 2000 os and the windows native > version of PostgresQL 8.0.1. I tried this command in psql and pgaccess. > Both return the same error - parser error at or near "as". Also I realised > later the type I was trying to create was a composite, not complex as I > wrote. Please copy and paste the exact command you're running and the exact error message. It's important to copy the actual command and error rather than type what you *think* they are because minor differences can sometimes matter. The following works for me in PostgreSQL 8.0.1: CREATE TYPE product AS (name varchar, price numeric); -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[BUGS] BUG #1568: concat
The following bug has been logged online: Bug reference: 1568 Logged by: helman Email address: 123@123.com PostgreSQL version: 8.0 Operating system: linux Description:concat Details: concat no accept null ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] plpgsql
hello,we have a postgres in windows and linux operating systems, then the problemis in plpgsql functions, which is i created a function with exceptionhandling in postgres 8.0.1 (windows operating system) which handle theexceptions very well, but i created the same function in (postgres8.0.1)linux operating system, it gives a syntax error near the exception,so please tell me, how can i resolve this problem.with regards,rajkumar Do you Yahoo!? Yahoo! Small Business - Try our new resources site!
Re: [BUGS] BUG #1558: memory leak in libpq connectDBStart()
I will post a patch in a few days. I am extremely busy and don't have adequate time. I apologize for not having posted more in the first place. On 27-Mar-05, at 1:12 AM, Tom Lane wrote: "Cade Cairns" <[EMAIL PROTECTED]> writes: The leak occurs when libpq can not establish a connection to the database server, in my case when it is not running. I believe that when a caller calls PQreset() or PQresetStart(), the subsequent call to connectDBStart() clobbers the previous value of addrlist in the PGconn. Presumably, closePGconn() should be destroying this value. Uh ... could we see a complete test case for this? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] BUG in pg_autovacuum - with patch
Karl Denninger <[EMAIL PROTECTED]> writes: > On Sat, Apr 02, 2005 at 12:16:00PM -0500, Matthew T. O'Connor wrote: >> Anyway, if pg_autovacuum is causing problems for cron I'm sure we would >> still benefit from this patch. However, while I claim no expertise >> related to detaching from the console, I will say that I copied the code >> detach code directly from postgresql itself, so I would have thought it >> was OK. Can someone more informed than I take a look at this patch? > You left out the closeout of the stdio streams from the Postgresql code you > copied. :-> Indeed. Patch applied (along with addition of the #includes it requires). regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #1568: concat
helman wrote: > > The following bug has been logged online: > > Bug reference: 1568 > Logged by: helman > Email address: 123@123.com > PostgreSQL version: 8.0 > Operating system: linux > Description:concat > Details: > > concat no accept null Concatting a NULL returns a NULL. You might want to use COALESCE() to return '' for NULL in the concat. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #1570: Double quotes in all field/table names must be
Christopher Brian Jurado wrote:
>
> The following bug has been logged online:
>
> Bug reference: 1570
> Logged by: Christopher Brian Jurado
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.0
> Operating system: Windows 2000
> Description:Double quotes in all field/table names must be optional!
> Details:
>
> The double quote(") for field/table names doesn't seem to be optional when
> using it in queries.
>
> I used pgAdmin under verion 8.0 to query any field on any table. A message
> says the relation does not exist. If I double-quote the field names and
> table names, then it works. Isn't it a very big burden to keep typing double
> quotes?
>
> I tried searching through the postgresql.conf file but nothing is there to
> control this behavior.
>
> In the documentation, they show samples without double quotes but it
> actually doesn't work when you try it.
The problem is that when you create a mixed upper/lowercase table or
column name using pgadmin, it double-quotes the identifier in CREATE,
but when you access it via SQL, you need to double-quote it yourself.
I think this is done because it allows pgadmin to preserve any case used
in the create, and pgadmin is consistent in quoting, but when you access
via SQL, you have to then do it too.
I think the only solution is to use only lowercase when creating objects
in pgadmin, unless you want to do double-quoting.
--
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 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [BUGS] BUG #1572: plpgsql in linux os
rajkumar wrote: > > The following bug has been logged online: > > Bug reference: 1572 > Logged by: rajkumar > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.0.1 > Operating system: linux > Description:plpgsql in linux os > Details: > > hello, > > we have a postgres in windows and linux operating systems, then the problem > is in plpgsql functions, which is i created a function with exception > handling in postgres 8.0.1 (windows operating system) which handle the > exceptions very well, but i created the same function in (postgres > 8.0.1)linux operating system, it gives a syntax error near the exception, > so please tell me, how can i resolve this problem. I can't imagine why that would happen. Can you show us the function? -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #1547: CREATE TYPE AS error
On Mon, Mar 28, 2005 at 12:51:42AM +, John Smith wrote: > I re-installed postgresql as a service and CREATE TYPE AS works. So I then > re-installed postgresql as a program (as I had originally done) and CREATE > TYPE AS doesn't work. > Perhaps you could check this on your system. Can't help there -- none of my systems distinguish between installing PostgreSQL as a "service" versus as a "program." We still haven't seen the *exact* command you're running and the *exact* error message (the command in your original message had a typo that results in a different error than the one you posted). Could you please post a complete set of steps that a person using the same platform could follow to reproduce the problem? Whenever possible, please copy and paste commands and output instead of typing them manually, to avoid introducing mistakes that aren't really present. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
