[SQL] schema

[Kenneth Gonsalves]

hi
where can i find infor about 'schema' in postgresql?
-- 
regards
kg

http://www.ootygolfclub.org

---(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: [SQL] schema

[Rüdiger Flotmann]

look here

http://sql-info.de/postgresql/schemas.html

On Sun, 16 Nov 2003 13:05:20 +0530
Kenneth Gonsalves <[EMAIL PROTECTED]> wrote:

> hi
> where can i find infor about 'schema' in postgresql?

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [SQL] Programatically switching database

[Tom Lane]

ow <[EMAIL PROTECTED]> writes:
> My concern though ... wouldn't pgSql server collapse when faced with
> transaction spawning across 100M+ records?

No.  You're extrapolating from Oracle-specific assumptions again.

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: [SQL] Programatically switching database

[Christopher Browne]

Clinging to sanity, [EMAIL PROTECTED] (Tom Lane) mumbled into her beard:
> ow <[EMAIL PROTECTED]> writes:
>> My concern though ... wouldn't pgSql server collapse when faced with
>> transaction spawning across 100M+ records?
>
> No.  You're extrapolating from Oracle-specific assumptions again.

Or from MySQL-specific assumptions :-).

It seems reasonable (absent of particular knowledge to the contrary)
that the size of a transaction might be _expected_ to be some sort of
constraint; it is quite surprising that it isn't, and I don't think
that's purely based on the mistake of assuming that the whole world
does things exactly like Oracle.
-- 
(format nil "[EMAIL PROTECTED]" "cbbrowne" "acm.org")
http://cbbrowne.com/info/postgresql.html
Rules  of  the  Evil  Overlord  #89.  "After  I  captures  the  hero's
superweapon, I  will not immediately  disband my legions and  relax my
guard because I believe whoever holds the weapon is unstoppable. After
all,   the  hero  held   the  weapon   and  I   took  it   from  him."


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

[SQL] Addition and subtraction on BIT type

[Yasir Malik]

Hello,
Is there a way to do addition and subtraction on BIT types?  For example,
for
creat table test (a BIT(3));
insert into test values (B'101');

select a + 1 from test; fails

and select a::smallint + 1 from test; also fails.

In addition, is there a way to change the bit of a bit string?  For
example change a 1 to a 0 or vice versa.

Any suggestions?
Thanks,
Yasir

---(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

[SQL] WITHOUT OIDS by default

[ow]

Hi,

Is there a way to specify that all tables should be created WITHOUT OIDS by
default?

Thanks





__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [SQL] Addition and subtraction on BIT type

[Yasir Malik]

Hello,
I think I am almost at a solution to my last question.  I can do
select int4(a) from test;
to convert to an integer.  So now addition and
subtraction can be done between bit types.  But how do I convert back to
BIT type?  If I do
select bit(int4(b'1001'));

I get the following message:
ERROR:  parser: parse error at or near "int4" at character 12

Can anyone tell me why the bit function is not working?  It's under the
pg_catalog schema.
Thanks,
Yasir

On Sun, 16 Nov 2003, Yasir Malik wrote:

> Date: Sun, 16 Nov 2003 11:18:03 -0500
> From: Yasir Malik <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Addition and subtraction on BIT type
>
> Hello,
> Is there a way to do addition and subtraction on BIT types?  For example,
> for
> creat table test (a BIT(3));
> insert into test values (B'101');
>
> select a + 1 from test; fails
>
> and select a::smallint + 1 from test; also fails.
>
> In addition, is there a way to change the bit of a bit string?  For
> example change a 1 to a 0 or vice versa.
>
> Any suggestions?
> Thanks,
> Yasir
>

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [SQL] WITHOUT OIDS by default

[Bruce Momjian]

ow wrote:
> Hi,
> 
> Is there a way to specify that all tables should be created WITHOUT OIDS by
> default?

No, and strangely it wasn't on the TODO list.  I just added it:

* Add GUC setting to make created tables default to WITHOUT OIDS

-- 
  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 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [SQL] Addition and subtraction on BIT type

[Stephan Szabo]

On Sun, 16 Nov 2003, Yasir Malik wrote:

> I think I am almost at a solution to my last question.  I can do
> select int4(a) from test;
> to convert to an integer.  So now addition and
> subtraction can be done between bit types.  But how do I convert back to
> BIT type?  If I do
> select bit(int4(b'1001'));
>
> I get the following message:
> ERROR:  parser: parse error at or near "int4" at character 12
>
> Can anyone tell me why the bit function is not working?  It's under the
> pg_catalog schema.

It's also the name of a type that takes a precision in parentheses, so
you'd have to say "bit"(...) with the quotes. As a note, I think
that's going to effectively return you a bit(32), so

sszabo=# select "bit"(int4(b'1001'));
   bit
--
 1001


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [SQL] Programatically switching database

[Greg Stark]

ow <[EMAIL PROTECTED]> writes:

> My concern though ... wouldn't pgSql server collapse when faced with
> transaction spawning across 100M+ records? 

The number of records involved really doesn't faze Postgres at all. However
the amount of time spent in the transaction could be an issue if there is
other activity in other schemas of the same database.

As long as the transaction is running none of the deleted or old updated data
in any schema of the database can be cleaned up by vacuum as postgres thinks
the big transaction "might" need to see it sometime.

So if the rest of the database is still active the tables and indexes being
updated may grow larger than normal. If it goes on for a _really_ long time
they might need a VACUUM FULL at some point to clean them up.

-- 
greg


---(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