Re: [SQL] function to format floats as money? (removing space padding)
On Thu, Apr 19, 2001 at 02:53:38PM -0500, Mark Stosberg wrote: > > Now that I've figured out that numeric is good for storing money, and > that I can format with like this: > > to_char(price, '9,999,999.99') as price > > Then I discovered that sometimes this returns leading spaces I don't > want. I can get rid of them like this: > > trim(to_char(price, '9,999,999.99')) as price > > Is that the recommended money formatting style, for amounts less than > 9,999,999.99? (assuming I'll tack on my own currency symbol? ). Other > there other general styles that folks like for this? Thanks, May be try docs, what? :-) test=# select to_char(123456, '9,999,999.99'); to_char --- 123,456.00 (1 row) test=# select to_char(123456, 'FM9,999,999.99'); to_char - 123,456 (1 row) test=# select to_char(123456, 'FM9,999,999.00'); to_char 123,456.00 (1 row) test=# select to_char(123, 'FM0,999,999.00'); to_char -- 0,000,123.00 (1 row) test=# select to_char(123456, 'LFM9,999,999.00'); to_char $123,456.00 (1 row) FM fill mode, skip blank spaces and zeroes (if not set '0' instead '9') L currency symbol (from actual locales) Right? Karel -- Karel Zak <[EMAIL PROTECTED]> http://home.zf.jcu.cz/~zakkr/ C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[SQL] Thank you
Hi. Thanx for your help with "PSQL to Access" problem. Mateusz Mazur [[EMAIL PROTECTED]] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [SQL] Client/Server Security question
Lonnie Cumberland wrote: > > Hello All, > > We are developing an application that will allow our websites to talk to our > database. > > In the interest of security, I am wondering if it is possible to turn off some > of the functions in the SQL command list such that a user can only communicate > to the database through our functions. > > What I mean is this. We have built a number of "C" extensions and PL/pgSQL > proceedures that will work on our database, but I only want to allow an outside > query to only one or two of our selected entry points. > > The webserver interface query statement might, for example, be able to only > call "select register_user(...)" or "select login_user()" and NONE of > the other PostgreSQL command functions. > > I only want to allow access to these functions from the outside world, but the > server needs to be able to execute all of the original functions without > restrictions. Lonnie, Have you checked the Postgres docs on security and access? It offers a lot of flexibility. For example, you can use a different postgres username to access the database from the outside world, in conjunction with using "grant" statements and views to give that user only the ability to perform specific actions on specific tables and views. If after reading the docs you still have specific questions about details that are not clear them, send a follow-up post with a more specific question and we can give you a more useful answer. :) -mark ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[ADMIN] select ... for update in plpgsql
Hi, I have a question about 'select ... for update'; according to the docs, clause 'for update' will lock selected rows, I believe it should be put into a begin; select ... for update; update ...; end; block. however, if I use it in a plpgsql function, do I need another pair of begin...end? or say begin...end in plpgsql can lock chosen rows until updated ALL ROWS? if not, do you have any suggestion? Jie LIANG St. Bernard Software 10350 Science Center Drive Suite 100, San Diego, CA 92121 Office:(858)320-4873 [EMAIL PROTECTED] www.stbernard.com www.ipinc.com ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[SQL] creating tables that are visible across databases
Hello, I'd like to create some tables that would visible across databases, much like the postgres system tables. These would be for "static" data, such as state and country codes, and geo-spatial data. I couldn't find this mentioned in the docs, but unless this feature of the system tables is magical, it appears to be possible. Did I miss an explanation in some docs, or could someone give me a pointer? Thanks! -mark personal website } Summersault Website Development http://mark.stosberg.com/{ http://www.summersault.com/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [SQL] creating tables that are visible across databases
Mark Stosberg <[EMAIL PROTECTED]> writes: > I'd like to create some tables that would visible across databases, > much like the postgres system tables. These would be for "static" data, > such as state and country codes, and geo-spatial data. I couldn't find > this mentioned in the docs, but unless this feature of the system tables > is magical, it appears to be possible. Unfortunately, it is magic ... see IsSharedSystemRelationName() for more info. Possibly you could hack that routine to allow certain other names to be considered shared. It looks to me like some of the uses of IsSharedSystemRelationName could/should be replaced by examining pg_class.relisshared, but in other places it's really necessary to determine sharedness with nothing but a relname to go on. This will all need to be rethought when we implement schemas, anyway... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [SQL] creating tables that are visible across databases
Mark Stosberg wrote: > > Hello, > > I'd like to create some tables that would visible across databases, > much like the postgres system tables. These would be for "static" data, > such as state and country codes, and geo-spatial data. I couldn't find > this mentioned in the docs, but unless this feature of the system tables > is magical, it appears to be possible. Did I miss an explanation in some > docs, or could someone give me a pointer? > Thanks! you could create the tables using a template database, in which case they would be created when you create a new database using that template (look at "createdb -T" to see how this works). this may not be what you're looking for because they wouldn't be shared across databases, they would just be copied into the new database when it was created. i don't think there's a way to have shared access to those tables. -- Jeff Hoffmann PropertyKey.com ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[SQL] plpgsql
I 've a question about begin...end in plpgsql does sql stmts in begin end; will go one transaction? i.e. begin...end have same meaning as sql stmts BEGIN...COMMIT?? if failed, transaction abort? if select..for update is used then another update stmt will wait on the same rows?? if begin...end in plpgsql connot have same functionality as sql, how can I ensure my sql stmts go one transaction?? thanks. Jie LIANG St. Bernard Software 10350 Science Center Drive Suite 100, San Diego, CA 92121 Office:(858)320-4873 [EMAIL PROTECTED] www.stbernard.com www.ipinc.com ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [SQL] plpgsql
On Fri, Apr 20, 2001 at 04:58:02PM -0700, Jie Liang wrote: > > I 've a question about begin...end in plpgsql > does > sql stmts in > begin > > end; > will go one transaction? Read the documentation (programmer's guide). It's all there. It's to answer your questions that we take the time to write docs in the first place :) Short answer: everything in your function is executed in one transaction. BEGIN and END in PL/pgSQL are NOT the same as in the transaction semantics. -Roberto -- +| http://fslc.usu.edu USU Free Software & GNU/Linux Club |--+ Roberto Mello - Computer Science, USU - http://www.brasileiro.net http://www.sdl.usu.edu - Space Dynamics Lab, Developer If at first you don't succeed, destroy all evidence that you tried. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster