Re: [GENERAL] A creepy story about dates. How to prevent it?
Is it desiarable to default postgresql.conf datestyle to match the locale? # # Locale settings # # (initialized by initdb -- may be changed) LC_MESSAGES = 'C' LC_MONETARY = 'C' LC_NUMERIC = 'C' LC_TIME = 'C' Another JPY 2 from the nattou gallery: Defaulting the datestyle to the locale setting makes sense to me. I wouldn't want it hardwired to the locale, of course. I would strongly request having heuristics off in the default settings. Two conditions I really want on the use of heuristics -- I want the date itself to include some fuzzy flag, and I want some way to reconstruct the original string. That way, if I want to design an application with tools for getting operator attention, etc., there are hooks in the data. But that feels to me like something for the application layer. -- Joel Rees, programmer, Kansai Systems Group Altech Corporation (Alpsgiken), Osaka, Japan http://www.alpsgiken.co.jp ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [pgsql-advocacy] [GENERAL] MySQL gets $19.5 MM
On Fri, Jun 20, 2003 at 11:14:02PM -0400, Tom Lane wrote: There are some, but I still disagree. The biggest advantage of PostgreSQL in my opinion has always been that it's a community project and not driven by some commercial interests. These are not mutually exclusive. Each developer has his own axe to grind, without doubt; I don't think it matters much whether his goals Okay, that's true. Actually what I wanted to say is the project must not rely on a kind of sponsorship. Maybe an example could make it more clear. Let's say a company approaches RH and says We need full replication and we're willing to pay for it, as this is still cheaper than buying the hwole stuff from Oracle or others.. Then RH pays you to do the work. I really like that. And it makes sense for all companies involved. What I do not like, and probably misunderstood in the original email, would be if RH says, Hey, we've contracted a good software developer to implement replication, no matter that he's not really interested in databases. And with no one paying RH for this work, they may decide at some point to just stop it. Or the developer leaves, etc. This of course is different than paying someone who's already a developer in this project. I love the way PGSQL is run, but have seen some unbelievable stuff in other projects. And it despises me to see companies, that do not even understand how free software development works, jump into a project and try to change it all, just to disappear after a few weeks. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-advocacy] [GENERAL] MySQL gets $19.5 MM
On Sat, Jun 21, 2003 at 11:40:52AM -0300, The Hermit Hacker wrote: I have no doubt that some of those features were 'pushed to the top of the TODO list' due to their business case, but I can't think of any that were against teh desires of the community ... were there? No, there were definitely not. I have no problem having TODOs list priorities changed and features developed due to business cases. What I meant to say was that companies should not just send some of their developers and act as if they want to take over. Sorry, I was just in a bad mood after seeing this stuff in another project. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Urgent : Postgresql Client for linux
On 23 Jun 2003 at 12:53, Kallol Nandi wrote: Is there any Postgresql client softwarefor linuxto connect to Postgresql database server on linux? Can somebody please provide me with the links or the installables if they have them already? How about psql? Thanks and Regards, Kallol Nandi, Systems Analyst, Indus Software - A Division of R Systems International Ltd., Tidel Park, Taramani, Chennai-600113, India. Phone: +91-44-22540014/6 Extn: 209 Fax: +91-44-22540017 Hand Phone: +91-9480222625 Email: [EMAIL PROTECTED] Visit us @ http://www.indussoft.com/ The information in this email is confidential, and intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are the addressee, the contents of this email are intended for your use only and it must not be forwarded to any third party, without first obtaining written authorization from the originator, or Indus Software. It may contain information, which is confidential and legally privileged, and the same shall not be used, or dealt with, by any third party, in any manner whatsoever, without the specific consent of Indus Software. The opinions expressed are those of the sender, and do not necessarily reflect those of the Indus Software. Well, to be polite, that size of signature is not good for your electronically social life.. Bye Shridhar -- Interpreter, n.:One who enables two persons of different languages to understand each other by repeating to each what it would have been to the interpreter's advantage for the other to have said. -- Ambrose Bierce, The Devil's Dictionary ---(end of broadcast)--- TIP 8: explain analyze is your friend
[GENERAL] SELECT @@IDENTITY
Okay, I did a quick search through both the general and SQL lists(1,2) trying to determine if there is a PostgreSQL construct equivalent to Microsoft SQL Server's SELECT @@IDENTITY. After performing an insert the database caches the last sequence number for each connection and the select retrieves that value. Thus if connection A and connection B each inserted into the same table they would each know what the value of the sequence was immediately after their insert. Is there any direct support for this? I know that I can manually code to select the nextval of a sequence but the syntactic sugar of SELECT @@IDENTITY is really nice. Many thanks! rjsjr 1 - The only valid query I could find was http://archives.postgresql.org/pgsql-general/2001-09/msg00523.php which is unanswered. 2 - The search engine for the archives seems to ignore the @@ in the search string so I ended up with a LOT of information on corporate identity and identity columns. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] [pgsql-advocacy] interesting PHP/MySQL thread
Hey! You stole my favorite laugh! My second favortie one is 'Nya, Nya, Ny' (Snidely Whiplash of Bulwinkle fame) Justin Clift wrote: Tom Lane wrote: snip We need to use this opportunity to encourage PHP folks to switch to PostgreSQL. Indeed. What can we do exactly? Hmmm... something along the lines of: PostgreSQL v7.4 released, including enhanced MySQL-PostgreSQL migration tools. Would make for an interesting move... not playing friendly at all. Muaaa H H ;- Regards and best wishes, Justin Clift regards, tom lane ---(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 ---(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 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] A creepy story about dates. How to prevent it?
I think rejecting the data is the best approach. I raises a big flag to the sysadmin or user. Tom Lane wrote: scott.marlowe [EMAIL PROTECTED] writes: The one thing that should absolutely be turned off is day/month swapping on dates of the form: 2003-02-22. Agreed on that. -DD-MM isn't used in the real world AFAIK, and it's reasonable to treat it as an error. I've seen little actual defense of the current behaviour, Other than me, I think you mean. dd/mm/ and mm/dd/ are inherently ambiguous in the real world, and when you can clearly determine what the intended meaning is, I think it's more reasonable to assume the datestyle isn't set correctly than to reject the data. 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]) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[GENERAL] different datatypes in index scan join
At the bottom of an email from this list, I saw: -(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 If that's so, then what is the recommended way to ensure an index is used if we want to join on different datatypes? Erik ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[GENERAL] MySQL/PG search times
We require ~* syntax for that, or upper()/lower(). Slowly the light dawns! If I anchor a ~ search on both ends, it is the same search as =. Duh! I converted the prototype over to use ~ and it is running much faster. I'll try to do some detailed timings against MySQL tonight. -- Mike Nolan ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] SELECT @@IDENTITY
On 6/23/03 12:58 PM, Robert J. Sanford, Jr. [EMAIL PROTECTED] wrote: Okay, I did a quick search through both the general and SQL lists(1,2) trying to determine if there is a PostgreSQL construct equivalent to Microsoft SQL Server's SELECT @@IDENTITY. After performing an insert the database caches the last sequence number for each connection and the select retrieves that value. Thus if connection A and connection B each inserted into the same table they would each know what the value of the sequence was immediately after their insert. Is there any direct support for this? I know that I can manually code to select the nextval of a sequence but the syntactic sugar of SELECT @@IDENTITY is really nice. Many thanks! Hi Robert: You'll want to consult the postgres docs about sequences. The function you're looking for is called currval(), and selects just what you want -- the most recent value delivered for a sequence over a given connection. (I've always been curious about how well this behaves, or not, with connection pooling). -- sgl ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] MySQL/PG search times
See the FAQ item about index usage. You have to anchor the start only. --- [EMAIL PROTECTED] wrote: We require ~* syntax for that, or upper()/lower(). Slowly the light dawns! If I anchor a ~ search on both ends, it is the same search as =. Duh! I converted the prototype over to use ~ and it is running much faster. I'll try to do some detailed timings against MySQL tonight. -- Mike Nolan -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 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
[GENERAL] SHM_QUEUE
just have a quick question. What i need to do is to create a shared memory structure (which i can do) and maintain in it a linked list which should be in shared memory too. I found the shmemqueue in postgres, but am having some problems using it. I just need to have the linked list store relation OID's. I see there is an Insert before and after which takes in an element and adds it to the queue. But the thing is - they are both SHM_QUEUE types. How can i convert an Oid to this type? Also, am i right in assuming that i can use this? I was looking for some examples of its use too. thanks nailah On Fri, 20 Jun 2003, Neil Conway wrote: Hi Nailah, I hope your summer is going well. I saw your post on -hackers regarding some problems with hash_search. The dynahash API can be a little bit picky -- IIRC, it requires you to NULL pad hash keys out to the appropriate length, rather than just using a regular NULL-terminated C-string. You weren't specific on the exact problem you were having, but perhaps taking a look at src/backend/commands/prepare.c (in PostgreSQL 7.3 or later) would be helpful: it is a simple example of manipulating a hash table of prepared statements that I wrote last summer. Since last I heard you guys were still working with 7.1, you can find the code in question here: http://developer.postgresql.org/cvsweb.cgi/~checkout~/pgsql-server/src/backend/commands/prepare.c?rev=1.18content-type=text/plain If that doesn't help, the usual fallback of breaking of gdb and stepping through the troublesome code might help track down the problem. BTW, I'm not subscribed to the -hackers list temporarily (just for the summer, as I'm busy w/ MS work), so my response to questions posted there will probably be erratic (I just browse the archives on the web occaisonally). -Neil ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [GENERAL] SELECT @@IDENTITY
It would be nice. keep table names short, name id columns the tablename plus id,
and let PG assign sequence names, so I can write:
set sql select currval(${tablename}_${tablename}id_seq) as lastid
in pltcl.
In other words,
create table foobar (
foobarid serial primary key,
otherfoo varchar);
creates a sequence named foobar_foobarid_seq every time.
I guess you could even define a function called @@IDENTITY(varchar) and give it the
table name... That's about as close as you are going to get.
Ian Harding
Programmer/Analyst II
Tacoma-Pierce County Health Department
[EMAIL PROTECTED]
Phone: (253) 798-3549
Pager: (253) 754-0002
Robert J. Sanford, Jr. [EMAIL PROTECTED] 06/23/03 10:58AM
Okay, I did a quick search through both the general and SQL lists(1,2)
trying to determine if there is a PostgreSQL construct equivalent to
Microsoft SQL Server's SELECT @@IDENTITY. After performing an insert the
database caches the last sequence number for each connection and the select
retrieves that value. Thus if connection A and connection B each inserted
into the same table they would each know what the value of the sequence was
immediately after their insert.
Is there any direct support for this? I know that I can manually code to
select the nextval of a sequence but the syntactic sugar of SELECT
@@IDENTITY is really nice.
Many thanks!
rjsjr
1 - The only valid query I could find was
http://archives.postgresql.org/pgsql-general/2001-09/msg00523.php which is
unanswered.
2 - The search engine for the archives seems to ignore the @@ in the
search string so I ended up with a LOT of information on corporate identity
and identity columns.
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [GENERAL] SELECT @@IDENTITY
I always use Steve's method (it's easier), but if you still want to do it in the sql-server way, you can use OIDs to fetch the id of the last INSERTed row. I don't know which programming language you are using, but are some examples: *plpgsql DECLARE myOid INTEGER; identity INTEGER; BEGIN INSERT INTO table VALUES (value1, value2, ... valueN); GET DIAGNOSTICS myOid=RESULT_OID; SELECT INTO identity pkfield FROM table WHERE OID=myOid; //do something with identity END; *php --- $res=pg_exec($conn, INSERT INTO table VALUES (value1, value2, ... valueN)); $oid=pg_getlastoid($res); $res=pg_exec($conn, SELECT pkfield AS id FROM table WHERE OID=$oid); $row=pg_fetch_array($res, 0, PGSQL_ASSOC); $identity=$row[id]; //do something with $identity *libpq PGResult *res=PQexec(con, INSERT INTO table VALUES (value1, value2, ... valueN)); Oid oid=PQoidValue(res); PQclear($res); char buffer[255]; sprintf(buffer, SELECT pkfield FROM table WHERE OID=%u, oid); res=PQexec(con, buffer); int identity=atoi(PQgetvalue(res, 0, 0)); PQclear($res); As you see, fetching from the sequence before inserting the row seems to be the easiest way. On Mon, 2003-06-23 at 15:11, Steve Lane wrote: On 6/23/03 12:58 PM, Robert J. Sanford, Jr. [EMAIL PROTECTED] wrote: Okay, I did a quick search through both the general and SQL lists(1,2) trying to determine if there is a PostgreSQL construct equivalent to Microsoft SQL Server's SELECT @@IDENTITY. After performing an insert the database caches the last sequence number for each connection and the select retrieves that value. Thus if connection A and connection B each inserted into the same table they would each know what the value of the sequence was immediately after their insert. Is there any direct support for this? I know that I can manually code to select the nextval of a sequence but the syntactic sugar of SELECT @@IDENTITY is really nice. Many thanks! Hi Robert: You'll want to consult the postgres docs about sequences. The function you're looking for is called currval(), and selects just what you want -- the most recent value delivered for a sequence over a given connection. (I've always been curious about how well this behaves, or not, with connection pooling). -- sgl ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) signature.asc Description: This is a digitally signed message part
Re: [GENERAL] A creepy story about dates. How to prevent it?
Tom Lane writes: Other than me, I think you mean. dd/mm/ and mm/dd/ are inherently ambiguous in the real world, and when you can clearly determine what the intended meaning is, I think it's more reasonable to assume the datestyle isn't set correctly than to reject the data. That might even make the slightest sense if the supposedly wrong datestyle would then stay switched. But the automatic switching only happens for a certain subsets of inputs and only in that instance. So if a user did really mean the opposite setting he will not be happy, and if the user did not mean the opposite setting he will not be happy either. So no one is happy. -- Peter Eisentraut [EMAIL PROTECTED] ---(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
[GENERAL] Eliminating start error message: unary operator expected
Title: Eliminating start error message: unary operator expected Hi Forum, What should I correct in order to eliminate the following error message on start: Executing /etc/rc.d/init.d/postgresql start .. Starting postgresql service: -sh: [: ==: unary operator expected [ OK ] We installed a v7.3.2 and PostgreSQL seems to be running very well but we want to get rid of this message. Thanks in advance for your response
Re: [GENERAL] A creepy story about dates. How to prevent it?
On Mon, 23 Jun 2003, Tom Lane wrote: scott.marlowe [EMAIL PROTECTED] writes: The one thing that should absolutely be turned off is day/month swapping on dates of the form: 2003-02-22. Agreed on that. -DD-MM isn't used in the real world AFAIK, and it's reasonable to treat it as an error. I've seen little actual defense of the current behaviour, Other than me, I think you mean. dd/mm/ and mm/dd/ are inherently ambiguous in the real world, and when you can clearly determine what the intended meaning is, I think it's more reasonable to assume the datestyle isn't set correctly than to reject the data. I thought the locale set that kind of behaviour didn't it? If so, then it's better to fail loudly then quietly accept bad data. But if the locale doesn't define such a thing, or it can't be set in postgresql.conf, the it's best to just avoid that date style altogether. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] A creepy story about dates. How to prevent it?
Peter Eisentraut wrote: Tom Lane writes: Other than me, I think you mean. dd/mm/ and mm/dd/ are inherently ambiguous in the real world, and when you can clearly determine what the intended meaning is, I think it's more reasonable to assume the datestyle isn't set correctly than to reject the data. That might even make the slightest sense if the supposedly wrong datestyle would then stay switched. But the automatic switching only happens for a certain subsets of inputs and only in that instance. So if a user did really mean the opposite setting he will not be happy, and if the user did not mean the opposite setting he will not be happy either. So no one is happy. I think we have had enough discussion to remove the question mark from this TODO item: * Allow current datestyle to restrict dates; prevent month/day swapping from making invalid dates valid Of course, if later discussion changes, I will re-add it. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] A creepy story about dates. How to prevent it?
scott.marlowe wrote: On Mon, 23 Jun 2003, Tom Lane wrote: scott.marlowe [EMAIL PROTECTED] writes: The one thing that should absolutely be turned off is day/month swapping on dates of the form: 2003-02-22. Agreed on that. -DD-MM isn't used in the real world AFAIK, and it's reasonable to treat it as an error. I've seen little actual defense of the current behaviour, Other than me, I think you mean. dd/mm/ and mm/dd/ are inherently ambiguous in the real world, and when you can clearly determine what the intended meaning is, I think it's more reasonable to assume the datestyle isn't set correctly than to reject the data. I thought the locale set that kind of behaviour didn't it? If so, then it's better to fail loudly then quietly accept bad data. But if the locale doesn't define such a thing, or it can't be set in postgresql.conf, the it's best to just avoid that date style altogether. Added to TODO, with question mark: * Have initdb set DateStyle based on locale? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: Don't 'kill -9' the postmaster
Re: [GENERAL] Eliminating start error message: unary operator
On Mon, 23 Jun 2003, Carlos wrote: Hi Forum, What should I correct in order to eliminate the following error message on start: Executing /etc/rc.d/init.d/postgresql start .. Starting postgresql service: -sh: [: ==: unary operator expected [ OK ] We installed a v7.3.2 and PostgreSQL seems to be running very well but we want to get rid of this message. How did you install postgresql (rpms, source code) and where did the startup script come from? ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [GENERAL] different datatypes in index scan join
On Monday 23 Jun 2003 7:08 pm, Erik Price wrote: At the bottom of an email from this list, I saw: -(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 If that's so, then what is the recommended way to ensure an index is used if we want to join on different datatypes? Cast your datatypes. For example, if you have an index on an int8 field foo you'd use something like: WHERE foo = 7::int8; This is because the '7' is going to be assumed an int4. You could use the more-standard cast() function rather than the '::' operator if you don't mind the typing. This is part of PG's tradeoff where a flexible type system means being quite cautious about assumptions. Readers who know an easy way of having their cake and eating it should contact the hackers list as soon as they've read the archive discussions on type issues. -- Richard Huxton ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] Eliminating start error message: unary operator expected
On 23/06/2003 20:16 Carlos wrote: Hi Forum, What should I correct in order to eliminate the following error message on start: Executing /etc/rc.d/init.d/postgresql start .. Starting postgresql service: -sh: [: ==: unary operator expected [ OK ] We installed a v7.3.2 and PostgreSQL seems to be running very well but we want to get rid of this message. Thanks in advance for your response You may have a typo in /etc/rc.d/init.d/postgresql. -- Paul Thomas +--+-+ | Thomas Micro Systems Limited | Software Solutions for the Smaller Business | | Computer Consultants | http://www.thomas-micro-systems-ltd.co.uk | +--+-+ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Eliminating start error message: unary operator
Postgresql was installed from RPMS, downloaded from the following url: ftp://ftp5.us.postgresql.org/pub/PostgreSQL/binary/v7.3.2/RPMS/redhat-7. 3/ The startup script was created when the rpms were installed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of scott.marlowe Sent: Monday, June 23, 2003 3:35 PM To: Carlos Cc: '[EMAIL PROTECTED]' Subject: Re: [GENERAL] Eliminating start error message: unary operator On Mon, 23 Jun 2003, Carlos wrote: Hi Forum, What should I correct in order to eliminate the following error message on start: Executing /etc/rc.d/init.d/postgresql start .. Starting postgresql service: -sh: [: ==: unary operator expected [ OK ] We installed a v7.3.2 and PostgreSQL seems to be running very well but we want to get rid of this message. How did you install postgresql (rpms, source code) and where did the startup script come from? ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] Eliminating start error message: unary operator
On Mon, 23 Jun 2003, Carlos wrote: Hi Forum, What should I correct in order to eliminate the following error message on start: Executing /etc/rc.d/init.d/postgresql start .. Starting postgresql service: -sh: [: ==: unary operator expected [ OK ] We installed a v7.3.2 and PostgreSQL seems to be running very well but we want to get rid of this message. Thanks in advance for your response You should ask your system admin to take a look. That init script should be pretty straight forward unless your admin has rolled his/her own complicated thing. -- Nigel J. Andrews ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Eliminating start error message: unary operator
Could you post a copy of the /etc/rc.d/init.d/postgresql file here? It may have gotten corrupted or have a simple syntax error in it. On Mon, 23 Jun 2003, Carlos Oliva wrote: Postgresql was installed from RPMS, downloaded from the following url: ftp://ftp5.us.postgresql.org/pub/PostgreSQL/binary/v7.3.2/RPMS/redhat-7. 3/ The startup script was created when the rpms were installed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of scott.marlowe Sent: Monday, June 23, 2003 3:35 PM To: Carlos Cc: '[EMAIL PROTECTED]' Subject: Re: [GENERAL] Eliminating start error message: unary operator On Mon, 23 Jun 2003, Carlos wrote: Hi Forum, What should I correct in order to eliminate the following error message on start: Executing /etc/rc.d/init.d/postgresql start .. Starting postgresql service: -sh: [: ==: unary operator expected [ OK ] We installed a v7.3.2 and PostgreSQL seems to be running very well but we want to get rid of this message. How did you install postgresql (rpms, source code) and where did the startup script come from? ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] Eliminating start error message: unary operator
Hi Scott,
There it goes. I also enclosed it in a text file.
Thanks you for your help
#! /bin/sh
# postgresqlThis is the init script for starting up the PostgreSQL
# server
#
# chkconfig: - 85 15
# description: Starts and stops the PostgreSQL backend daemon that
handles \
# all database requests.
# processname: postmaster
# pidfile: /var/run/postmaster.pid
# Version 6.5.3-2 Lamar Owen
# Added code to determine if PGDATA exists, whether it is current
version
# or not, and initdb if no PGDATA (initdb will not overwrite a
database).
# Version 7.0 Lamar Owen
# Added logging code
# Changed PGDATA.
#
# Version 7.0.2 Trond Eivind Glomsrd [EMAIL PROTECTED]
# use functions, add conditional restart
# Version 7.0.3 Lamar Owen [EMAIL PROTECTED]
# Check for the existence of functions before blindly using them
# in particular -- check for success () and failure () before using.
# More Cross-distribution support -- PGVERSION variable, and docdir
checks.
# Version 7.1 Release Candidate Lamar Owen [EMAIL PROTECTED]
# initdb parameters have changed.
# Version 7.1.2 Trond Eivind Glomsrd [EMAIL PROTECTED]
# Specify shell for su
# Handle stop better - kill unwanted output, make it wait until the
database is ready
# Handle locales slightly differently - always using C isn't a valid
option
# Kill output from database initialization
# Mark messages for translation
# Version 7.1.2-2.PGDG Lamar Owen [EMAIL PROTECTED]
# sync up.
# Karl's fixes for some quoting issues.
# Version 7.2b2 Lamar Owen [EMAIL PROTECTED]
# version change.
# Version 7.2 final. Lamar Owen [EMAIL PROTECTED]
# reload from Peter E.
# Eliminate the pidof postmaster test in stop -- we're using pg_ctl so
we don't need pidof.
# Tested the $? return for the stop script -- it does in fact propagate.
# TODO: multiple postmasters.
# VErsion 7.3 Lamar OWen [EMAIL PROTECTED]
# Multiple postmasters, courtesy Karl DeBisschop
# PGVERSION is:
PGVERSION=7.3
# Source function library.
INITD=/etc/rc.d/init.d
. $INITD/functions
# Get function listing for cross-distribution logic.
TYPESET=`typeset -F`
# Get config.
. /etc/sysconfig/network
# Find the name of the script
NAME=`basename $0`
# Set defaults for port and database directory
PGPORT=5432
export PGDATA=/var/lib/pgsql
if [ -f $PGDATA/PG_VERSION ] [ -d $PGDATA/base/template1 ]
then
echo Using old-style directory structure
else
export PGDATA=/var/lib/pgsql/data
fi
# Override defaults from /etc/sysconfig/pgsql if file is present
[ -f /etc/sysconfig/pgsql/${NAME} ] . /etc/sysconfig/pgsql/${NAME}
export PGDATA
export PGPORT
export PGOPTS
# Check that networking is up.
# Pretty much need it for postmaster.
[ ${NETWORKING} = no ] exit 0
[ -f /usr/bin/postmaster ] || exit 0
start(){
PSQL_START=$Starting ${NAME} service:
# Check for the PGDATA structure
if [ -f $PGDATA/PG_VERSION ] [ -d $PGDATA/base ]
then
# Check version of existing PGDATA
if [ `cat $PGDATA/PG_VERSION` != '7.3' ]
then
SYSDOCDIR=(Your System's documentation
directory)
if [ -d /usr/doc/postgresql-$PGVERSION ]
then
SYSDOCDIR=/usr/doc
fi
if [ -d /usr/share/doc/postgresql-$PGVERSION ]
then
SYSDOCDIR=/usr/share/doc
fi
if [ -d /usr/doc/packages/postgresql-$PGVERSION
]
then
SYSDOCDIR=/usr/doc/packages
fi
if [ -d
/usr/share/doc/packages/postgresql-$PGVERSION ]
then
SYSDOCDIR=/usr/share/doc/packages
fi
echo
echo $An old version of the database format was
found.\nYou need to upgrade the data format before using
PostgreSQL.\nSee $SYSDOCDIR/postgresql-$PGVERSION/README.rpm-dist for
more information.
exit 1
fi
# No existing PGDATA! Initdb it.
else
echo -n $Initializing database:
if [ ! -d $PGDATA ]
then
mkdir -p $PGDATA
chown postgres.postgres $PGDATA
chmod go-rwx $PGDATA
fi
# Make sure the locale from the initdb is preserved for
later startups...
[ -f /etc/sysconfig/i18n ] cp /etc/sysconfig/i18n
$PGDATA/../initdb.i18n
# Just in case no locale was set, use en_US
[ ! -f /etc/sysconfig/i18n ] echo LANG=en_US
$PGDATA/../initdb.i18n
# Is expanded this early to be used in the command su
runs
echo export LANG LC_ALL LC_CTYPE LC_COLLATE LC_NUMERIC
LC_CTYPE
Re: [GENERAL] [pgsql-advocacy] interesting PHP/MySQL thread
On Tue, 2003-06-24 at 04:58, Matthew Nuzum wrote: I too started doing php stuff because of the need to do a web front end for a database. Prior to that I had no database experience at all and the wealth of PHP/MySQL tutorials made it easy for me to learn both. Then there are those of us who don't use PHP and don't think that it is the right choice for enterprise class database front ends... The force of PostgreSQL is that you have the right to choose the front end for webapps. I do not think that it is a good idea to tie just one to the database. PHP does not have a very good image when it comes to stability or security for example. It may be better marketing to say you can use PostgreSQL with Zope, Tcl/tk, Python, JSP or even PHP. Rather than you _HAVE_ to use PHP as a front end if you want to run MySQL because, if you want to use anything else, tough... Cheers Tony Grant -- www.tgds.net Library management software toolkit, redhat linux on Sony Vaio C1XD, Dreamweaver MX with Tomcat and PostgreSQL ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[GENERAL] PostgreSQL Core Welcomes New Member
The PostgreSQL Core would like to publicly welcome welcome Josh Berkus as our newest member. Josh is being included especially as a liason between the source-programmer and non-source-programmer contributors to PostgreSQL, in an effort to expand PostgreSQL volunteer documentation, advocacy, and vendor relations efforts. In addition to being actively involved in the project for the last 4 years, he previously helped create the Marketing Project of OpenOffice.org, and launched the pgsql-performance list and PostgreSQL's first local user group (SFPUG). ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
