[GENERAL] dynamic database
hello, 1) can i create a dynamic database in postgresql 7.0 ? if so how many number of databases (maximum number of databases) a postgresql 7.0 installation support ? 2)can i restrict the size of a database while creating it ? later sometime can i change the same ? 3) can i restrict the sizeof a table while creating it ? can i change it later sometime ? i am in immediate need of your help . please reply as soon as possible ? thanx in advance .
Re: [GENERAL] Column types via ODBC interface
Tom Lane wrote: Matt Goodall [EMAIL PROTECTED] writes: f10 decimal(9,2) SQL_VARCHAR, 254 SQL_DECIMAL, 9 f11 numeric(9,2) SQL_VARCHAR, 254 SQL_DECIMAL, 9 The 6.5 ODBC driver doesn't know about type numeric, so it returns its default assumption, which is varchar as above. The 7.0 version knows about numeric, however. Great - I'll upgrade to v 7.x then. The SQL type returned for "bool" appears to be a user-settable option. Sorry if I've missed something obvious in the docs but is that a postgres setting or an odbc driver manager setting? The choices made for floating types look reasonably plausible. If you think they're wrong, you'll need to argue why, not just assert that you think they are. It's easy enough to change the ODBC driver's SQL type = Postgres type mapping if there's a better definition than what we're using... regards, tom lane Fair enough - I should have explained my reasoning here. Here's an bit from table 3-1.Postgres Data Types in the 6.5.3 documentation: Postgres Type SQL92 or SQL3 Type ~ ~~ ... float4/8float(p) float8 real, double precision ... I was expecing that to mean that float4/8 would map to an ODBC SQL_FLOAT and float8 would map to either SQL_REAL or SQL_DOUBLE. Cheers, Matt. -- Matt Goodall | Isotek Electronics Ltd email: [EMAIL PROTECTED] | Claro House, Servia Road Tel: +44 113 2343202 | Leeds, LS7 1NL Fax: +44 113 2342918 | England
[GENERAL] existing but not-existing database.
hi, i created a database called todojamon. (i wanted to make up of an old database trying to copy the same directoy to ../base/todojamon as before). but it does not work. i deleted the directory. now i want to restart the procedure creating a new database called todojamon. but it answers psql todojamon FATAL 1: Database 'todojamon' does not exist. We know this because the directory '/usr/local/pgsql/data/base/todojamon' does not exist. You can create a database with the SQL command CREATE DATABASE. To see what databases exist, look at the subdirectories of '/usr/local/pgsql/data/base/'. Connection to database 'todojamon' failed. FATAL 1: Database 'todojamon' does not exist. We know this because the directory '/usr/local/pgsql/data/base/todojamon' does not exist. You can create a database with the SQL command CREATE DATABASE. To see what databases exist, look at the subdirectories of '/usr/local/pgsql/data/base/'. if psql template1 [inside postgres] template1= create database todojamon; ERROR: createdb: database 'todojamon' already exists ERROR: createdb: database 'todojamon' already exists how can i delete todojamon database?? thanks in advance. marcos [EMAIL PROTECTED]
Re: [GENERAL] existing but not-existing database.
psql todojamon FATAL 1: Database 'todojamon' does not exist. We know this because the directory '/usr/local/pgsql/data/base/todojamon' does not exist. You can create a database with the SQL command CREATE DATABASE. To see what databases exist, look at the subdirectories of '/usr/local/pgsql/data/base/'. Connection to database 'todojamon' failed. FATAL 1: Database 'todojamon' does not exist. We know this because the directory '/usr/local/pgsql/data/base/todojamon' does not exist. You can create a database with the SQL command CREATE DATABASE. To see what databases exist, look at the subdirectories of '/usr/local/pgsql/data/base/'. if psql template1 [inside postgres] template1= create database todojamon; ERROR: createdb: database 'todojamon' already exists ERROR: createdb: database 'todojamon' already exists how can i delete todojamon database?? You should have deleted the database with "destroydb". Now you can edit "by hand" the pg_database table, which is the system table where the available databases are stored. Use standard SQL commands like "SELECT * FROM pg_database" and etc. to delete the entry for your database. Paulo Jan. DDnet.
Re: [GENERAL] Re: [SQL] oracle rownum equivalent?
At 06:47 PM 6/7/00 -0400, Cary O'Brien wrote: thanks for the response. oid is equivalent to oracle rowid. I think there is a fundamentel difference between oid and rownum. Oid is just a serial number. Rownum is a long string that tells oracle where exactly the row is. So *I think* rownum can be used for fast lookups, where oid, unless indexed, can't. Other than that they are the same pretty much. -- cary i'll have to respectfully disagree with you on your interpretation of rownum. in oracle, rownum tells only the relative position of a row in a result set. also, it is an integer value starting at 1 up to nrows retrieved and is used, for the most part, to limit the result set and not for fast lookups. it also can be used in a DML statement within a function, such as mod(), to aid in generating a value. the point here is moot though, as postgres doesn't have an equivalent and i'll have to learn to live without that small piece of oracle and enjoy what i see as the greater benefits of postgres. :) mikeo
Re: [GENERAL] Re: [SQL] oracle rownum equivalent?
At 06:47 PM 6/7/00 -0400, Cary O'Brien wrote: thanks for the response. oid is equivalent to oracle rowid. I think there is a fundamentel difference between oid and rownum. Oid is just a serial number. Rownum is a long string that tells oracle where exactly the row is. So *I think* rownum can be used for fast lookups, where oid, unless indexed, can't. Other than that they are the same pretty much. -- cary i'll have to respectfully disagree with you on your interpretation of rownum. in oracle, rownum tells only the relative position of a row in a result set. also, it is an integer value starting at 1 up to nrows retrieved and is used, for the most part, to limit the result set and not for fast lookups. it also can be used in a DML statement within a function, such as mod(), to aid in generating a value. the point here is moot though, as postgres doesn't have an equivalent and i'll have to learn to live without that small piece of oracle and enjoy what i see as the greater benefits of postgres. Arrg. That's what I get for emailing late at night without checking (my Oracle book is in the office). Where I typed rownum I meant rowid. You are 100% correct about rownum. You can use rownum for things like select * from foo where rownum = 20 Where in postgresql you would say select * from foo limit 20 What I meant to say, and failed, was that in Oracle, rowid "psuedo-column" are hex encoded strings containing the block, row, and file where the tuple is stored. So lookup on unindexed rowid *should* be fast, although this is not spelled out in my ancient Oracle book. If you want a PostgreSQL lookup using oid to be fast, you need an index, I think. PostgreSQL oid is kind of like, but not exactly the same as either oracle rownum or oracle rowid. Sorry for the confusion. -- cary
Re: [GENERAL] Composite Types
Tom Lane wrote: [EMAIL PROTECTED] writes: I appreciate any help I can get on this...Recently, I've been experimenting with the user defined base-types (using CREATE TYPE) with successful results. But, when it comes to handling classes as composite types, things are not as straight forward. The function-returning-composite-type feature is something we inherited from Berkeley Postgres it doesn't fit into SQL92 at all, Right. And the "doesn't fit into SQL92" is why I would like to get rid of "composite" and "SET OF composite" values for functions. We need to get them back in a clearly defined way for stored procedures, but what's possible now is broken in concept, and doesn't make much sense to me anyway. and I don't think any of the current crop of developers even understand it very well. It's certainly suffering from bit-rot. The "hobbies" examples in the regression tests seem to be meant to illustrate how it was supposed to work, but I don't find them either intelligible or persuasive. It was the so called "nested dot" syntax of PG4.2 - which was never released as nested dot, but was working if someone used attrname(func-returns-tuple(args)) in the POSTQUEL language! The downside was, that a query needing more than one attrib from the func, ran it multiple times, returning separate sets. Thus, JOINing over them in fact! I consider this broken from the very first attempt, because such a function has to go into the rangetable (FROM clause). If I type: select content from stuff; I get: content --- 136585664 (1 row) I believe you are looking at a numeric equivalent of a pointer-to- TupleTableSlot there. Somewhere in the mists of Berkelian prehistory, there must have been some code that did something useful with that kind of function result, but I sure as heck can't find much trace of it now. Exactly correct. The original POSTQUEL parser had support to extract a single attribute from a function returning a tuple. Someone also attempted to add a targetlist to Func nodes. Both attempts seemed to fail, so we ended up with a "broken by concept" state. I have been thinking lately that functions returning tuples might fit into SQL92 better as table sources. That is, instead of select foo(bar).whatdoyouwritehere ... we could write something like select elementa,elementc+1 from foo(bar) That doesn't work at the moment, of course, but it's something we could think about causing to work as part of the querytree redesign planned for 7.2. Thoughts anyone? What I reffered to with "subselecting RTEs" as often as I could. Seems you finally got me (sorry for my bad english :-). If something is broken, fix it. If something is broken by concept, fix the concept and reimplement the feature. This time, the concept is broken, so let's first decide how it should appear on the query level. The FROM foo(bar) above perfectly fits into the new querytree structure we've outlined during breakfast in San-Francisco. What a time, we worked from breakfast until after dinner - it was great. Anyway, we know that this one would fit into the new concept, but are we sure anything else would? For the rewriter, I know that VIEWs will be a nobrainer. But all other rewriting rules on INSERT/UPDATE/DELETE, turning views into tables, don't appear to be that easy any more. Actually we have a central rangetable, and the target is just "0" (meaning client) or the RTE index of the query. With the new querytree concept, we'd loose the central rangetable, so application of modifying rules might not be that simple any more. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] #
Re: [GENERAL] Postgresql
On Wed, 7 Jun 2000, Mihai Gheorghiu wrote: The following is a quote from a consultant's opinion on my intention to migrate to Postgresql. Quote: The use of Postgres is cautioned for mission critical data by the developers of Postgres themselves. Unquote. Please comment. Maybe way back in the pre-v6.0 days ... 3 years ago ...
[GENERAL] Re: FreeBSD PostgreSQL7 port and v7.0.2
On Thu, 8 Jun 2000, John Daniels wrote:
Hi:
Thanks, I check into that. I have assumed, from my own reading of the
release history, that:
1) 7.0.1 fixes some minor bugs, and
2) 7.0.2 was released so quickly after 7.0.1 because some documentation was
left out as an oversight (which was probably already
in of 7.0.0).
Which led me to conclude that:
1) there should be no change to the patches that make 7.0.x run with
FreeBSD
2) there are no new files from 7.0.0 to 7.0.2
I am cc-ing pgsql-general@postgresql to see if anyone there can confirm the
above as fact.
the only caveat to 2 ... there are now docs, which we missed including in
v7.0.1 ... are those installed anywhere?
John
From: Trevor Johnson [EMAIL PROTECTED]
To: John Daniels [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: Re: FreeBSD PostgreSQL7 port and v7.0.2
Date: Thu, 8 Jun 2000 00:07:10 -0400 (EDT)
Hi:
Hi, John.
1. I changes all references of 7.0.0 to 7.0.2
2. I changed the MD5 file to reflect the MD5 checksums for 7.0.2
Is there anything else that I need to do or be aware of before
making the port? (Frankly, I would be surprised if there is any
need to change the v7.0.0 patches to make v7.0.2 work under
FreeBSD.)
At http://www.postgresql.org/news.html it says:
This is essentially a cleanup of v7.0 and the addition of some
missing docs from v7.0.1.
[...]
Added documentation to tarball
which sounds as though there may be new files which could pertain to
use under FreeBSD. If that's the case, you'll want to update
pkg/PLIST so it lists them.
--
Trevor Johnson
http://jpj.net/~trevor/gpgkey.txt
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-ports" in the body of the message
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
