[HACKERS] Help Needed
For my project (main memory DBMS), I hv written a main memory filesystem. Idea is, the primary copy of data will reside in main memory. (Workable only for small size data, at most 2GB). Now, I want to plug this filesystem with Postgres, so that, instead of Unix filesystem, this main memory filesystem(MMFS) will now store the data. I want to know, how to plug it with Postgres. i.e. whether replacing all calls to Unix filesystem by calls to MMFS is enough, or do I need to do something else/more. I am really a newbie to Postgres. So, can someone pls guide me, abt how should I go. _ Ameya S Sakhalkar, Sr. Postgraduate Student, CSE, C-720, H12, IIT Bombay. email: [EMAIL PROTECTED] Phone: 9892252239 Visit me at: http://www.cse.iitb.ac.in/~ameya ---(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
[HACKERS] order by problems FIXED
Hi all It was a setlocale problem Thanks Lorne -- --- [EMAIL PROTECTED] --- ---(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
[HACKERS] more on character fields
Hi all, It would appear that none of the comparision functions work on my OS/2 port for columns defined as char or varchar. With a table "smalvar" of two columns, one varchar and the other name acol nn -- AA AA CC a "select * from smalvar where acol = '' " will return all three rows a "select * from smalvar where nn = 'AA' " will return two rows. a "select * from smalvar where nn = 'CC' " will return two rows. I realize I have a problem with comparisons as any thing that does a comparison using a char or varchar field fails, whereas doing the same operation with a "name" column succeeds and with an integer column succeeds. What I would like help with is locating where in the code the comparisons take place for these functions. Please help? Thank you Lorne -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] More on Order by
OK I believe that.. But why does order by work on a "name" column but not a "char(10)" column. See my earlier (posted later because of problems) e-mail. Lorne In <[EMAIL PROTECTED]>, on 12/26/04 at 02:16 PM, Michael Fuhr <[EMAIL PROTECTED]> said: >On Sun, Dec 26, 2004 at 02:57:08PM -0500, [EMAIL PROTECTED] wrote: >> So what is difference between a "name" and a char(10)??? >See the "Character Types" section in the "Data Types" chapter of the >documentation. >"The name type exists _only_ for storage of identifiers in the internal >system catalogs and is not intended for use by the general user." -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Problem with ORDER BY
The previous one of these seems to being blocked because of the big
attachments.
Short stuff is embedded in this e-mail.
Hi all,
I have a problem in my os/2 port of postgreSQL v8.0 and I am hoping
someone can help me with it.
When I create a database and use the commands shown below the select ...
order by works for the pg_tables view column "tablename" but fails for
the addresslist column "city". The output from my test database is in
out.log
I ran a complete createdb processed the addresslist.sql with -d3 output
and the results are in debug.log and psql output in out2.log. There was a
failure when I typoed the createdb statement.
select ... order by will work for the columns defined as integer but not
for character
Where is the best place to start looking???
Does this work properly on other platforms (I hope so).
Thanks for any help.
Lorne Sunley
SQL to execute --
create table addresslist (name char(40), address char(40), city char(40),
telephone char(20), postalcode char(10), numfield integer); insert into
addresslist values ('Aardvark', '101 Street', 'Sometown', '999-000', 'H0H
0H0', 1); insert into addresslist values ('Beebop', '901 Street',
'Sometown', '888-000', 'T0T 0H0', 2); insert into addresslist values
('Xerox', '801 Street', 'Sometown', '777-000', 'K0H 0H0', 3); insert into
addresslist values ('Middling', '1101 Street', 'Sometown', '333-000', 'R0R
0H0', 4); insert into addresslist values ('Lost', '1 Avenue', 'Sometown',
'456-000', 'X0X 0H0', 5); insert into addresslist values ('Timeout', '202
Street', 'Sometown', '789-000', 'T0H 0H0' ,5); insert into addresslist
values ('What Where Who', '555 Street', 'Where', '911-000', 'T0H 0H0', 6);
insert into addresslist values ('Catalog', '989 Street', 'LittleBurg',
'911-001', 'T0H 0H0', 7); insert into addresslist values ('Premium', '21
Street', 'Bigcity', '222-', 'W0W 0H0', 8); insert into addresslist
values ('ToastMaster', '13 Street', 'Waytown', '444-000', 'W0R 0H0', 9);
insert into addresslist values ('Dumbthing', '888 Street', 'Thistown',
'555-000', 'W0T 0H0', 9); select city from addresslist order by city desc;
select tablename from pg_tables order by tablename desc;
select city from addresslist order by city asc;
select tablename from pg_tables order by tablename asc;
select city, numfield from addresslist order by numfield asc; select city,
numfield from addresslist order by numfield desc;
--- end of SQL -
- results ---
CREATE TABLE
INSERT 17325 1
INSERT 17326 1
INSERT 17327 1
INSERT 17328 1
INSERT 17329 1
INSERT 17330 1
INSERT 17331 1
INSERT 17332 1
INSERT 17333 1
INSERT 17334 1
INSERT 17335 1
city
--
Thistown
Sometown
Sometown
Sometown
Sometown
Sometown
Where
LittleBurg
Bigcity
Waytown
Sometown
(11 rows)
tablename
-
sql_sizing_profiles
sql_sizing
sql_packages
sql_languages
sql_implementation_info
sql_features
pg_type
pg_trigger
pg_tablespace
pg_statistic
pg_shadow
pg_rewrite
pg_proc
pg_operator
pg_opclass
pg_namespace
pg_listener
pg_largeobject
pg_language
pg_inherits
pg_index
pg_group
pg_description
pg_depend
pg_database
pg_conversion
pg_constraint
pg_class
pg_cast
pg_attribute
pg_attrdef
pg_amproc
pg_amop
pg_am
pg_aggregate
addresslist
(36 rows)
city
--
Thistown
Sometown
Sometown
Sometown
Sometown
Sometown
Where
LittleBurg
Bigcity
Waytown
Sometown
(11 rows)
tablename
-
addresslist
pg_aggregate
pg_am
pg_amop
pg_amproc
pg_attrdef
pg_attribute
pg_cast
pg_class
pg_constraint
pg_conversion
pg_database
pg_depend
pg_description
pg_group
pg_index
pg_inherits
pg_language
pg_largeobject
pg_listener
pg_namespace
pg_opclass
pg_operator
pg_proc
pg_rewrite
pg_shadow
pg_statistic
pg_tablespace
pg_trigger
pg_type
sql_features
sql_implementation_info
sql_languages
sql_packages
sql_sizing
sql_sizing_profiles
(36 rows)
city | numfield
--+
Re: [HACKERS] More on Order by
On Sun, Dec 26, 2004 at 02:57:08PM -0500, [EMAIL PROTECTED] wrote: > So what is difference between a "name" and a char(10)??? See the "Character Types" section in the "Data Types" chapter of the documentation. "The name type exists _only_ for storage of identifiers in the internal system catalogs and is not intended for use by the general user." -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] More on Order by
Hi All I have discovered that when I use a table like this create table whois (acol name); and insert a few rows, the order by clause works correctly. I dug into the database init stuff to find that the table pg_class column relname is where the pg_tables column tablename comes from. That column is defined as a 'name' datatype. So what is difference between a "name" and a char(10)??? Lorne -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Where do pg_hba.conf include files live?
Tom Lane wrote: > The SGML docs state that include files referenced by "@foo" constructs > in pg_hba.conf "must be in the same directory as pg_hba.conf". The > actual implementation, however, assumes they must be in DataDir. > This is no longer the same thing after the introduction of the > data_directory and hba_file GUC parameters. > > It seems to me that in a context where you are storing pg_hba.conf in a > separate configuration directory, putting the include files in that same > directory is the behavior you'd want. On the other hand, the contents > of those files would often be data-cluster-specific (since they'd > typically be lists of user or database names). Maybe the code behavior > is still sensible. > > One thing that's probably *not* sensible either way is that the code > forcibly prepends the directory name even if it's fed "@/abs/path". > I think if an absolute path is given it should be honored. That would > give an "out" for DBAs who want whichever behavior we don't provide. > > The changes to fix the code, if we decide the code is wrong rather than > the docs, do not look very large; so I don't think we need to decide > this on the basis of it being too late to change for 8.0. Good point. I agree @ should be relative to pg_hba.conf directory and not datadir, and that absolute paths should work. -- 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/faqs/FAQ.html
Re: [HACKERS] Updateable views
--- Greg Stark <[EMAIL PROTECTED]> escribió: > > > - What if we cannot create one of the three > >rules? > >Make the rule not updateable at all? > >Or create the rules we can? (i think this is > >the correct) > > I seem to be in the minority here. But I think > creating complex rules to fiddle with the updates > to translate them to the underlying tables is the > wrong approach. > > I think you want to extend the SQL syntax to allow > updating views, and implement plan nodes and > executor functionality to handle them. What if someone want his views to be readonly? with rules he can just drop rule. In the approach you mention he cannot. > So things like this works: > > UPDATE (SELECT id,val FROM t) SET val=0 where id < > 100 > You really do things like that??? For what?? I'm asking because i do not know any situation when it becomes usefull. Views, conceptually, should have the same behavior a table has, because you can use it to let some people view part of your info without letting them touch the table. Sometimes you need they can update the fields they can see, but then how u can prevent them touching other fields they have no rights to? Updateable views are handy for that. In your example is obvious that you can access to the t table, why not do the update directly?? Besides, this enforce to create privileges per columns rather than per table. > Then the rules you create on the views are just like > the rules for SELECT, they simply mechanically > replace the view with the view definition. > > I think this is the right approach because: > > a) I think creating the general rules to transform >an update into an update on the underlying table >will be extremely complex, and you'll only ever be >able to handle the simplest cases. By handling >the view at planning time you'll be able to >handle arbitrarily complex cases limited only by >whether you can come up with reasonable semantics. > I don't think is *extremely complex* to create the rules; but yes, there will be limitations. > b) I think it's aesthetically weird to have >functionality that's only accessible via creating >DDL objects and then using them, and not >accessible directly in a single SQL DML command. >Ie, it would be strange to have to create >a "temporary view" just in order to execute an >update because there's no equivalent syntax >available for use directly. > alter table (SELECT id,val FROM t) alter column val set default 3; > > General Restrictions!!! > > --- > > - The column target list holds column fields only, > > that are retrieved from one base relation / view > > only. (NO joined views). > > I know there are other uses for updatable views (eg > implementing column-based security policies) but the > _only_ reason I ever found them useful in Oracle > was precisely for joined views. The NOTE i included in my last post says that oracle do that with user_updateable_columns view and i suggest the creation (or the extension of pg_attribute) of a catalog to implement this. And i state that can be useful to create joined updateable views. > They're the Oracle blessed method for achieving the > same performance win as Postgres's FROM clause. > > So in Oracle you can do: > > UPDATE (select a.val as newval, b.b_id, b.val from > a,b where a.b_id = b.b_id) SET val = newval > I think Postgres's UPDATE ... FROM is a lot more clear to understand. regards, Jaime Casanova _ Do You Yahoo!? Información de Estados Unidos y América Latina, en Yahoo! Noticias. Visítanos en http://noticias.espanol.yahoo.com ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
