[SQL] Default timestamp value
As a precursor to this question, I read: CREATE TABLE Date/Time Types (and corresponding input/output) Date/Time Functions ...but I still don't see how to have the default value of a timestamp to be the time at which the individual record is inserted. I just get the time I created the table. Specifically, what to put where the '?' is at. ... "TimeDate" TIMESTAMP DEFAULT ? ... I tried 'now' and 'current' but it just makes the default value the time when I create the table, and 'current' gives me the word 'current' back in psql, so I imagine I'm not taking that in quite the right way =) I can see why it does this for both of these, althought in the docs, it says current is current time, deferred, but I dunno what that means. Any help or pointers to a nice resource? IMHO, the PG docs are a great reference, but not much in the way of terrific examples =) - r
Re: [SQL] Default timestamp value
"Rob S." wrote: > > As a precursor to this question, I read: > > CREATE TABLE > Date/Time Types (and corresponding input/output) > Date/Time Functions > > ...but I still don't see how to have the default value of a timestamp to be > the time at which the individual record is inserted. I just get the time I > created the table. Specifically, what to put where the '?' is at. > > ... "TimeDate" TIMESTAMP DEFAULT ? ... Hallo Rob, an example, which works by me [PostgreSQL 6.4.2 on i686-pc-linux-gnu, compiled by gcc 2.7.2.]: CREATE TABLE "session" ( "zeitpunkt" timestamp DEFAULT now ( ) NOT NULL, "sid" int4 NOT NULL, "nummer" int4 NOT NULL, "status" character varying NOT NULL, "host" inet); Ade Thomas > > I tried 'now' and 'current' but it just makes the default value the time > when I create the table, and 'current' gives me the word 'current' back in > psql, so I imagine I'm not taking that in quite the right way =) I can see > why it does this for both of these, althought in the docs, it says current > is current time, deferred, but I dunno what that means. > > Any help or pointers to a nice resource? IMHO, the PG docs are a great > reference, but not much in the way of terrific examples =) > > - r
[SQL] SQL functions - bug?
I realized the following facts using SQL language functions: There is a function "function_y(...)" which returns int4; a table z and two functions: CREATE FUNCTION function_x1() RETURNS int4 AS ' select function_y(any_of_fields_of_table_z) from z; ' LANGUAGE 'SQL'; This calls function_y(...) only with the first row of the query output of the select statement. Instead of this, CREATE FUNCTION function_x2() RETURNS int4 AS ' select function_y(z_field_any) from z; select 1; ' LANGUAGE 'SQL'; works properly (the important thing for me is to call function_y with all rows of the select query). So, the second workaround is OK, but in my opinion function_x1() also should call function_y(...) for as many rows as exist in the output. Is this a bug? I am using 7.0 (8th May). Regards, Zoltan
[SQL] cron job INSERT appears to bail.
Hi, I have mirrored our Web site to a client's intranet, using tried and tested techniques. Every day I generate a new file containing some table drops, some table creates and about 7000 insert statements. This is ftp'd up to our ISP, where a cronjob uses 'psql -f' to update the Website data. Great, all is well. The intranet mirror for the client later grabs the file from the ISP and attempts the same 'psql -f' but appears to stop after a few inserts. Running the 'psql -f' from the command line works just fine. So.. what is it about the cron job that is limiting? I know this is probably a systems issue, rather than a PostgreSQL issue per se, but I am completely stumped. And this is all a little embarassing! Linux Mandrake 7.0, Intel platform, postgres 6.5.2 -- # Allan Kellyhttp://www.plotsearch.co.uk # (+44) (0)1506 417130 x 229 # [EMAIL PROTECTED] .. # /Software Engineer/i. ... . # -- * . . .. . # "If you are a Visual Basic programmer, * . . . # these details are none of your business."* . . . # Mr Bunny's Guide to Active X, by Carlton Egremont III * . . # -- vi: set noet tw=80 sts=4 ts=8 : .
[SQL] [OT] Book on Postgres (Not a question)
Hello, I know this is off topic but I thought you might like to know that the following book explains how to compile, install and secure postgresql. It can be purchased from http://www.linuxports.com/ (just click on the books) and 20% goes back to the OpenSource Documentation Fund. THe Original Announcement: This email is to announce the new OpenDocs Publication: Securing and Optimizing Linux: RedHat Edition Including with the book are the Linux Central CD's of: RedHat 6.2 RedHat 6.2 Powertools The retail price for the book is 49.95 but if you preorder it no the price is only 39.95!. And of course since it is an OpenDocs Publication a percentage of the Gross Profits go to the Open Source Documentation Fund. Below is an abbreviated Table of Contents: Linux Installation Descriptions of programs packages we must uninstall for securities reasons Descriptions of programs that must be uninstalled after installation of the server Linux General Security Linux General Optimization Linux Kernel Linux TCP/IP Network Management Linux IPCHAINS Linux Masquerading and Forwarding Linux Compiler functionality Linux sXid Linux Logcheck Linux PortSentry Linux OpenSSH Client/Server Linux SSH2 Client/Server Linux Tripwire 2.2.1 Linux Tripwire ASR 1.3.1 Linux GnuPG Set Quota on your Linux system Linux DNS and BIND Server Linux Sendmail Server (includes 8.10.1) Linux IMAP & POP Server Enable IMAP or POP via the tcp-wrappers inetd super server Linux OPENSSL Server Linux FreeS/WAN VPN Linux OpenLDAP Server Linux PostgreSQL Database Server Linux Squid Proxy Server Linux MM - Shared Memory Library for Apache Linux Apache Web Server Linux Webalizer Linux FAQ-O-Matic Linux Webmail IMP Linux Samba Server Linux FTP Server Linux Backup and Restore Tweaks, Tips and Administration tasks Obtaining Requests for Comments (RFCs) Thanks! [EMAIL PROTECTED] -- -- CommandPrompt - http://www.commandprompt.com OpenDocs, LLC. - http://www.opendocs.org LinuxPorts - http://www.linuxports.com LDP - http://www.linuxdoc.org -- Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. --
[SQL] CREATE FUNCTION- Table as argument
I am running PostgreSQL 6.5.3 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66. I have currently a table like the following: TABA: a|start|finish -+-+-- R|4| 8 S|6|10 I want the output a table with start incremented by 1, and fininsh as the maximum of fininish in all records. Quite sensibliy, my attemp to use a SQL statement like 'SELECT a,start+1,max(finish) from taba' failed with "ERROR: Illegal use of aggregates or non-group column in target list". Hence, I tried to create a function that would return the maximum fininsh attribute in a table. Hence, CREATE function findMax() RETURNS int4 AS 'SELECT max(finish) from taba;' LANGUAGE 'sql' and then SELECT a, start+1,findMax() from taba; does work, but the problem is, I need a generic function that would find the maximum finish attribute not just for a unique table. Hence I tried the following: CREATE function findMax(varchar) RETURNS int4 AS 'SELECT max(finish) from $1;' LANGUAGE 'sql' However, this results in "ERROR: parser: parse error at or near "$1""; I have tried to substitute varchar with TEXT and NAME, but still the same error persists. Changing $1 to \$1 does not help either. I have even tried alias using: CREATE FUNCTION findMax(varchar) RETURNS int4 AS 'DECLARE tabName ALIAS FOR $1; BEGIN SELECT max(finish) from tabName; END; ' LANGUAGE 'sql'; this results in "ERROR: parser: parse error at or near "alias"" Does anyone know how I could take in a table name as argument to a SQL function? Get your free email from AltaVista at http://altavista.iname.com
Re: [SQL] Default timestamp value
"Rob S." <[EMAIL PROTECTED]> writes: > ...but I still don't see how to have the default value of a timestamp to be > the time at which the individual record is inserted. I just get the time I > created the table. Specifically, what to put where the '?' is at. > ... "TimeDate" TIMESTAMP DEFAULT ? ... In 7.0 either "'now'" or "now()" should work, eg regression=# create table foo (f1 int, f2 timestamp default now()); CREATE regression=# insert into foo values(1); INSERT 395192 1 regression=# insert into foo values(2); INSERT 395193 1 regression=# select * from foo; f1 | f2 + 1 | 2000-06-05 11:15:25-04 2 | 2000-06-05 11:15:28-04 (2 rows) Versions before 7.0 are not entirely consistent about this, but I believe the explicit function call now() will work the way you want in any version. BTW, this *is* covered in the FAQ, see http://www.postgresql.org/docs/faq-english.html#4.22 regards, tom lane
Re: [SQL] cron job INSERT appears to bail.
Allan Kelly <[EMAIL PROTECTED]> writes: > The intranet mirror for the client later grabs the file from the ISP > and attempts the same 'psql -f' but appears to stop after a few > inserts. "Appears to stop" is hardly enough of a problem description to allow useful advice to be given. Does the process quit, or just hang up waiting for something? Is there anything reported in the postmaster log? (You might try firing up the psql run with environment variable PGOPTIONS = "-d2" to cause individual queries to be logged.) regards, tom lane
Re: [SQL] Default timestamp value
Tom Lane wrote: > > "Rob S." <[EMAIL PROTECTED]> writes: > > ...but I still don't see how to have the default value of a timestamp to be > > the time at which the individual record is inserted. I just get the time I > > created the table. > Versions before 7.0 are not entirely consistent about this, but I > believe the explicit function call now() will work the way you want > in any version. you can also use the value CURRENT_TIMESTAMP, which is standard SQL. you have to be careful about using 'now' as a default, though. i have a tendancy to put type qualifications on most of the things i write ever since i had problems with getting an index to be used on an int2 field. the key to the faq is that you can't put a type qualification after the 'now', otherwise it won't work. so in 7.0, if you create a table like any of these: create table foo (f1 int, f2 timestamp default now()); create table foo (f1 int, f2 timestamp default 'now'); create table foo (f1 int, f2 timestamp default CURRENT_TIMESTAMP); it will work. if you do it like this, it won't: create table foo (f1 int, f2 timestamp default 'now'::datetime); create table foo (f1 int, f2 timestamp default 'now'::timestamp); it will give you the time that the table was created. it's just a little gotcha that might frustrate people in a similar situation. jeff
Re: [SQL] SQL functions - bug?
Kovacs Zoltan Sandor <[EMAIL PROTECTED]> writes: > There is a function "function_y(...)" which returns int4; a table z and > two functions: > CREATE FUNCTION function_x1() RETURNS int4 AS ' > select function_y(any_of_fields_of_table_z) from z; > ' LANGUAGE 'SQL'; > This calls function_y(...) only with the first row of the query output of > the select statement. Instead of this, > CREATE FUNCTION function_x2() RETURNS int4 AS ' > select function_y(z_field_any) from z; > select 1; > ' LANGUAGE 'SQL'; > works properly (the important thing for me is to call function_y with > all rows of the select query). So, the second workaround is OK, but in my > opinion function_x1() also should call function_y(...) for as many rows as > exist in the output. Is this a bug? The only bug I could see in function_x1() is that perhaps the system should raise an error if the final select of the function tries to yield more than one tuple, rather than just stopping its evaluation after one tuple. (In effect, there's an implicit LIMIT 1 on that select.) You've declared a function returning int4; that is to say, *one* int4 per call. No more. The behavior you are after requires a different declaration: regression=# CREATE FUNCTION function_x1() RETURNS SETOF int4 AS ' regression'# select f1 from int4_tbl; regression'# ' LANGUAGE 'SQL'; CREATE regression=# select function_x1(); ?column? - 0 123456 -123456 2147483647 -2147483647 (5 rows) Functions returning sets have a lot of restrictions on them, some of which you will no doubt find out the hard way :-(. But the basic feature works. regards, tom lane
[SQL] Vacuum problem in my system ?
Hi people. For a few days, i've been experiencing some problems. There's a cron-scheduled vacuum, performed every night. But, on the morning, my DBs can't be accessed. Error message says "DB busy, too many connected" (about so). And, ps ax|grep post shows a lot of backends, waiting for an unlock that never comes. I'm using RH 5.2, with glibc 2.1.2, and gcc 2.95.2. This problem appeared after upgrading to Pg 7.0 RC1 (i'm now using Pg 7.0.1, but am still experiencing the same trouble). I've compiled the source tarball: [PostgreSQL 7.0.1 on i686-pc-linux-gnu, compiled by gcc 2.95.2] (Kernel is 2.2.15) To have more information, I've finally modified my cron, adding the verbose parameter. So I've got this: 0 4 * * * psql greffe -c 'vacuum verbose analyze' The output I got this morning through email can be found at the end of this email. It shows something wrong happened. Does anyone have a hint to help me find the origin of a problem I appear to be the only one to experience on this mailing-list ? TIA. Regards, Fabrice Scemama Subject: Cron psql greffe -c 'vacuum verbose analyze' Date: 5 Jun 2000 03:00:01 - From: [EMAIL PROTECTED] (Cron Daemon) To: [EMAIL PROTECTED] NOTICE: --Relation pg_type-- NOTICE: Pages 4: Changed 0, reaped 2, Empty 0, New 0; Tup 212: Vac 10, Keep/VTL 1/0, Crash 0, UnUsed 0, MinLen 105, MaxLen 109; Re-using: Free/Avail. Space 8440/400; EndEmpty/Avail. Pages 0/1. CPU 0.00s/0.00u sec. NOTICE: Index pg_type_typname_index: Pages 4; Tuples 212: Deleted 10. CPU 0.00s/0.00u sec. NOTICE: Index pg_type_oid_index: Pages 2; Tuples 212: Deleted 10. CPU 0.00s/0.00u sec. NOTICE: Rel pg_type: Pages: 4 --> 3; Tuple(s) moved: 1. CPU 0.00s/0.00u sec. NOTICE: Index pg_type_typname_index: Pages 4; Tuples 212: Deleted 1. CPU 0.00s/0.01u sec. NOTICE: Index pg_type_oid_index: Pages 2; Tuples 212: Deleted 1. CPU 0.00s/0.00u sec. NOTICE: --Relation pg_attribute-- NOTICE: Pages 78: Changed 2, reaped 3, Empty 0, New 0; Tup 5856: Vac 156, Keep/VTL 16/0, Crash 0, UnUsed 0, MinLen 98, MaxLen 98; Re-using: Free/Avail. Space 15816/15816; EndEmpty/Avail. Pages 0/3. CPU 0.00s/0.04u sec. NOTICE: Index pg_attribute_relid_attnum_index: Pages 31; Tuples 5856: Deleted 156. CPU 0.00s/0.01u sec. NOTICE: Index pg_attribute_relid_attnam_index: Pages 72; Tuples 5856: Deleted 156. CPU 0.00s/0.01u sec. NOTICE: Rel pg_attribute: Pages: 78 --> 76; Tuple(s) moved: 16. CPU 0.00s/0.00u sec. NOTICE: Index pg_attribute_relid_attnum_index: Pages 31; Tuples 5856: Deleted 16. CPU 0.01s/0.00u sec. NOTICE: Index pg_attribute_relid_attnam_index: Pages 72; Tuples 5856: Deleted 16. CPU 0.01s/0.00u sec. NOTICE: --Relation pg_proc-- NOTICE: Pages 26: Changed 0, reaped 0, Empty 0, New 0; Tup 1083: Vac 0, Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 177, MaxLen 229; Re-using: Free/Avail. Space 0/0; EndEmpty/Avail. Pages 0/0. CPU 0.00s/0.00u sec. NOTICE: Index pg_proc_proname_narg_type_index: Pages 24; Tuples 1083. CPU 0.00s/0.00u sec. NOTICE: Index pg_proc_oid_index: Pages 6; Tuples 1083. CPU 0.00s/0.01u sec. NOTICE: --Relation pg_class-- NOTICE: Pages 3: Changed 0, reaped 1, Empty 0, New 0; Tup 184: Vac 10, Keep/VTL 1/0, Crash 0, UnUsed 14, MinLen 106, MaxLen 144; Re-using: Free/Avail. Space 2996/0; EndEmpty/Avail. Pages 0/0. CPU 0.00s/0.00u sec. NOTICE: Index pg_class_relname_index: Pages 4; Tuples 184: Deleted 10. CPU 0.00s/0.00u sec. NOTICE: Index pg_class_oid_index: Pages 2; Tuples 184: Deleted 10. CPU 0.00s/0.00u sec. NOTICE: --Relation pg_indexes-- NOTICE: Pages 0: Changed 0, reaped 0, Empty 0, New 0; Tup 0: Vac 0, Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 0, MaxLen 0; Re-using: Free/Avail. Space 0/0; EndEmpty/Avail. Pages 0/0. CPU 0.00s/0.00u sec. NOTICE: --Relation pg_group-- NOTICE: Pages 0: Changed 0, reaped 0, Empty 0, New 0; Tup 0: Vac 0, Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 0, MaxLen 0; Re-using: Free/Avail. Space 0/0; EndEmpty/Avail. Pages 0/0. CPU 0.00s/0.00u sec. NOTICE: Index pg_group_sysid_index: Pages 2; Tuples 0. CPU 0.00s/0.00u sec. NOTICE: Index pg_group_name_index: Pages 2; Tuples 0. CPU 0.00s/0.00u sec. NOTICE: --Relation pg_database-- NOTICE: Pages 1: Changed 0, reaped 1, Empty 0, New 0; Tup 9: Vac 0, Keep/VTL 0/0, Crash 0, UnUsed 1, MinLen 81, MaxLen 91; Re-using: Free/Avail. Space 7376/0; EndEmpty/Avail. Pages 0/0. CPU 0.00s/0.00u sec. NOTICE: --Relation pg_attrdef-- NOTICE: Pages 3: Changed 0, reaped 0, Empty 0, New 0; Tup 67: Vac 0, Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 159, MaxLen 672; Re-using: Free/Avail. Space 0/0; EndEmpty/Avail. Pages 0/0. CPU 0.00s/0.00u sec. NOTICE: Index pg_attrdef_adrelid_index: Pages 2; Tuples 67. CPU 0.00s/0.00u sec. NOTICE: --Relation pg_relcheck-- NOTICE: Pages 0: Changed 0, reaped 0, Empty 0, New 0; Tup 0: Vac 0, Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 0, MaxLen 0; Re-using: Free/Avail. Space 0/0; EndEmpty/Avail. Pages 0/0. CPU 0.00s/0.00u sec. NOTICE: Index pg_relcheck_rcrelid_index: Pages 2; Tu
Re: [SQL] Vacuum problem in my system ?
Fabrice Scemama <[EMAIL PROTECTED]> writes: > [ vacuum appears to be coredumping ] That's odd ... not so much that vacuum could be failing, which is probably a garden-variety bug; but it sounds like the postmaster is failing to do the system restart that it should do after one of the backends fails. Is there anything showing up in the postmaster log when this happens? As for tracking the immediate vacuum problem, the failed backend should have left a core dump file in the database directory (.../data/base/DBNAME/core). Can you get a backtrace from that with gdb? Something like gdb path/to/postgres path/to/core bt quit should do. regards, tom lane
RE: [SQL] Default timestamp value
Thanks very much everyone! > BTW, this *is* covered in the FAQ, see > http://www.postgresql.org/docs/faq-english.html#4.22 Ahh, but I did look at a FAQ! I just went back and checked the date, I guess I shouldn't have just skimmed down the page: Last updated: Mon Oct 14 08:05:23 EDT 1996. That's the last time I search for a FAQ before checking the PG page. ;) Thanks again everybody =) - r
[SQL] Problem with array
Hi, Instead of using select car_name from car_table where car_property[1]='1995'; (*) Can I use where car_property['year']='1995'; in Postgres?? I want to use a more descriptive name than just using index for the array (not just during insertion but as well as to specify it in table creation!) Any idea? Thanks. - Bernie begin:vcard n:Huang;Bernie tel;fax:(604)664-9195 tel;work:(604)664-9172 x-mozilla-html:TRUE org:Environment Canada;Standards and Technology Services adr:;;700-1200 West 73 Ave.;Vancouver;BC;V6P 6H9;Canada version:2.1 email;internet:[EMAIL PROTECTED] title:Programmer x-mozilla-cpt:;0 fn:Bernie Huang end:vcard
Re: [SQL] Vacuum problem in my system ?
No core dump could be found within the data/base/* directories. The cron is executed by user root, but on my system root is a PostgreSQL superuser. Tom Lane wrote: > > Fabrice Scemama <[EMAIL PROTECTED]> writes: > > [ vacuum appears to be coredumping ] > > That's odd ... not so much that vacuum could be failing, which is > probably a garden-variety bug; but it sounds like the postmaster is > failing to do the system restart that it should do after one of the > backends fails. Is there anything showing up in the postmaster log > when this happens? > > As for tracking the immediate vacuum problem, the failed backend > should have left a core dump file in the database directory > (.../data/base/DBNAME/core). Can you get a backtrace from that > with gdb? Something like > gdb path/to/postgres path/to/core > bt > quit > should do. > > regards, tom lane
[SQL] Index Scans
Oops, ignore that first post :) I am unable to get the following query to use an index scan, any suggestions? Query - SELECT username, acctsessiontime, acctinputoctets, acctoutputoctets FROM radacct WHERE ((tstamp >= '06-04-2000 00:00:00-04') AND (tstamp < '06-05-2000 00:00:00-04') AND (acctstatustype = 'Stop')) ORDER BY username ASC; Indexes (I created this many for testing only) --- CREATE INDEX idx_radacct_1 ON radacct (username,acctstatustype,tstamp); CREATE INDEX idx_radacct_2 ON radacct (username,acctstatustype); CREATE INDEX idx_radacct_3 ON radacct (username,tstamp); CREATE INDEX idx_radacct_4 ON radacct (acctstatustype,tstamp); CREATE INDEX idx_radacct_5 ON radacct (tstamp); CREATE INDEX idx_radacct_6 ON radacct (acctstatustype); CREATE INDEX idx_radacct_7 ON radacct (username); CREATE INDEX idx_radacct_8 ON radacct (tstamp,acctstatustype); Here is the output of explain on the queries: radius=# VACUUM ANALYZE; VACUUM radius=# set enable_seqscan=on; SET VARIABLE radius=# explain **INSERT QUERY** NOTICE: QUERY PLAN: Sort (cost=16528.92..16528.92 rows=5588 width=24) -> Seq Scan on radacct (cost=0.00..16181.12 rows=5588 width=24) EXPLAIN radius=# set enable_seqscan=off; SET VARIABLE radius=# explain **INSERT QUERY** NOTICE: QUERY PLAN: Sort (cost=17500.82..17500.82 rows=5588 width=24) -> Index Scan using idx_radacct_8 on radacct (cost=0.00..17153.01 rows=5588 width=24) EXPLAIN Thanks Michael Fork - CCNA - MCP - A+ Network Support - Toledo Internet Access - Toledo Ohio
[SQL] Finding number of updated rows in pl/pgsql
Is there any easy way to find out the number of rows updated by a update or insert statement in pl/pgsql? I searched the mailing list archives and didn't come up with anything. Oh and BTW doing an insert/update combined with select following won't exactly work as it is possible for this table to have duplicated data in it. Thanks, Aaron
[SQL] nested sub-select ?
Hi, Anyone know if Postgresql can replicate this Oracle nested sub-select query (it uses the Oracle CURSOR operator) SELECT deptname, CURSOR (SELECT Empname, Sal FROM emp WHERE emp.deptno=department.deptno) AS Employees FROM department Where deptno=x I want to output a nested list like this (ie. rows from the aliased employees table within their respective department) Deptname: Sales Employees-row-no: 1 Empname: Smith Sal: 2000 Employees-row-no: 2 Empname: Jones Sal: 1000 It would be very useful to have the ability to nest multiple CURSOR statements (or equivalent) within the SELECT clause. Any help appreciated. TIA Chris Martin Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Re: [SQL] Vacuum problem in my system ?
Fabrice Scemama <[EMAIL PROTECTED]> writes: > No core dump could be found within the data/base/* directories. Hm. When I've seen a backend crash without leaving a core file, it's usually because the backend ran up against the system's per-process memory limit. (Many kernels seem to choose not to drop a core file when they kill a process for memory exhaustion.) You could check that theory by watching the process's memory usage with "top". Anything in the postmaster log? regards, tom lane
[SQL] Is it possible to "truncate" a LOB?
Suppose that I have created a LOB, written a bunch of data to it, and committed. Is it now possible to rewrite the LOB to contain a lesser amount of data? In other words can I do the equivalent of UNIX open(..., O_WRONLY | O_TRUNC) or ftruncate(...) on a LOB? Or am I forced to delete the existing LOB and create a new one if I want to shrink the size of the stored data? -- Steve
[SQL] moving DB
Hi all! well, can somebody tell me how to move a DB (e.g. I have a DB named NET in PC1 under pg6.5.3 and I want to put it in PC2 under pg7.0) should I copy just the data/base/NET/ directory and the paste it in the data/base of the PC2... which are the exactly steps... :o) thanx Rocael Get free email and a permanent address at http://www.netaddress.com/?N=1
