Re: [SQL] Syntax error while altering col-type
> -Original Message- > > That's exactly the error you'd get on a pre-8.0 system that doesn't > support altering a column's type. Are you looking at 8.0 > documentation > but running a 7.x server? What does "SELECT version();" show? Yes, that's it. I am looking into an 8.0 doc while running 7.4. I'm a little bit perplexed now... is it really the case that pre 8.0 systems aren't able to change col-types? thx > > -- > Michael Fuhr > http://www.fuhr.org/~mfuhr/ > ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [SQL] Implementing queue semantics (novice)
Thank you for this rather detailed example. I already learned something and omitted a fault. There should be enogh to implement such a Queue. :-) > -Original Message- > From: Andrew Hammond [mailto:[EMAIL PROTECTED] > Sent: Mittwoch, 12. Jänner 2005 17:19 > To: KÖPFERL Robert > Cc: 'pgsql-sql@postgresql.org' > Subject: Re: [SQL] Implementing queue semantics (novice) > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > The name for what you're looking to build is a concurrent batch > processing system. Here's a basic one. > > - -- adding processes > > BEGIN; > > INSERT INTO queue (queue_id, processing_pid, processing_start, > ~ processing_status, foreign_id) > VALUES (DEFAULT, NULL, NULL, > ~ (SELECT queue_status_id FROM queue_status WHERE name = 'pending'), > ~ foreign_id); > > COMMIT; > > > - -- removing processes > > BEGIN; > > SELECT queue_id, foreign_id FROM queue > WHERE processing_status = (SELECT queue_status_id FROM queue_status > ~ WHERE name = 'pending') > ORDER BY queue_id LIMIT 1 > FOR UPDATE; > > UPDATE queue > SET processing_pid = ?, > ~ processing_start = now(), > ~ processing_status = (SELECT queue_status_id FROM queue_status WHERE > ~ name = 'active') > WHERE id = ?; > > COMMIT; > > - -- client code does whatever it's going to do here > > BEGIN; > > SELECT 1 FROM queue > WHERE queue_id = ? AND processing_pid = ? > FOR UPDATE; > > - -- confirm that it exists > > DELETE FROM queue WHERE queue_id = ? > > INSERT INTO queue_history (queue_id, processing_pid, processing_start, > ~ processing_complete, processing_status, foreign_id) > VALUES (queue_id, processing_pid, processing_start, now(), > ~ (SELECT queue_status_id FROM queue_status WHERE name = 'done'), > ~ foreign_id); > > COMMIT; > > - -- a seperate process reaps orphaned entries should processing fail. > > BEGIN; > SELECT queue_id, processing_pid FROM queue > WHERE now() - processing_start > 'some reasonable interval'::interval > AND processing_status = (SELECT queue_status_id FROM > queue_status WHERE > ~ name = 'active' FOR UPDATE; > > - -- for each entry, check to see if the PID is still running > > UPDATE queue > SET > ~ processing_pid = NULL, > ~ processing_start = NULL, > ~ processing_status = (SELECT id FROM queue_status WHERE name > = 'pending') > WHERE id = ?; > > COMMIT; > > There are more complicated approaches available. If you plan to have > multiple machines processing, you probably want to add a > processing_node > entry too. > > > KÖPFERL Robert wrote: > | Hi, > | > | since I am new to writing stored procedures I'd like to ask > first bevore I > | do a mistake. > | > | I want to implement some kind of queue (fifo). There are n > users/processes > | that add new records to a table and there are m consumers > that take out > | these records and process them. > | It's however possible for a consumer to die or loose > connection while > | records must not be unprocessed. They may rather be processed twice. > | > | This seems to me as a rather common problem. But also with > atomicy-holes to > | fall into. > | How is this commonly implemented? > | > | > | I can imagine an 'add' and a 'get' function together with > one aditional > | 'processed' timestamp-column? > | > | > | > | Thanks for helping me do the right. > | > | ---(end of > broadcast)--- > | TIP 4: Don't 'kill -9' the postmaster > > > - -- > Andrew Hammond416-673-4138[EMAIL PROTECTED] > Database Administrator, Afilias Canada Corp. > CB83 2838 4B67 D40F D086 3568 81FC E7E5 27AF 4A9A > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.2.5 (GNU/Linux) > > iD8DBQFB5U3kgfzn5SevSpoRAoesAKCAZkr61I5knCw9tIr8rlO0xri7YACgifrn > N01nXZY8UKmIlTnGkngHKUo= > =UXRk > -END PGP SIGNATURE- > ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [SQL] Syntax error while altering col-type
KÖPFERL Robert wrote: >I'm a little bit perplexed now... is it really the case that pre 8.0 systems >aren't able to change col-types? I would guess that the column type altering code is just short hand for creating a new column of the correct type, copying the old column into the new one, deleting the old column, and renaming the new column to be the same as the old one. That is just a guess though! But if it's all bundled inside a transaction it should have about the same semantics, shouldn't it? Cheers, Sam ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[SQL] Columns into rows.
I'm working with a quite flat table schema (think: mySQL ;)), and I want to divide it into two tables. Lets start with how it looks now: CREATE TABLE old_table ( id serial PRIMARY KEY, body text, path_a varchar(1024), gendate_a date, path_bb varchar(1024), gendate_bb date, path_ccc varchar(1024), gendate_ccc date ); I want to have: CREATE TABLE new_table ( id serial PRIMARY KEY, body text ); CREATE TABLE new_table_paths ( id integer NOT NULL REFERENCES (new_table), pathtype NOT NULL varchar(10), path varchar(1024), gendate date, PRIMARY KEY(id,pathtype) ); ...what I'm looking for is how to, most efficiently write a join between new_table and new_table_paths so it looks like old_table (for compatibility (for other people)). I'm thinking about a trigger on schema-table (with pathtypes), which would automagically update view whenever schema-table is updated (new pathtype (like 'a', 'bb', 'ccc')) is added/removed); but this is implementation. Now, for the join. I can write: SELECT * FROM (SELECT id, path AS path_a FROM new_table_paths WHERE id = <> AND pathtype = 'a') AS a NATURAL FULL OUTER JOIN (SELECT id, path AS path_bb FROM new_table_paths WHERE id = <> AND pathtype = 'bb') AS bb; [ and so on... ] And its fast; however if I move WHERE id = <> outside selects (for views), it first "materializes" old layout, and then selects id... total waste. SELECT * FROM (SELECT id, path AS path_a FROM new_table_paths WHERE pathtype = 'a') AS a NATURAL FULL OUTER JOIN (SELECT id, path AS path_bb FROM new_table_paths WHERE pathtype = 'bb') AS bb WHERE id = <>; I wonder if you know other way to write this join so it has good performace? Once again, I need a SELECT since I want a VIEW. :-) Regards, Dawid ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [SQL] Columns into rows.
On Thu, 13 Jan 2005 11:26:04 +0100, Dawid Kuroczko <[EMAIL PROTECTED]> wrote: > I can write: > > SELECT * FROM (SELECT id, path AS path_a FROM new_table_paths WHERE id > = <> AND pathtype = 'a') AS a NATURAL FULL OUTER JOIN (SELECT id, > path AS path_bb FROM new_table_paths WHERE id = <> AND pathtype = > 'bb') AS bb; [ and so on... ] > > And its fast; however if I move WHERE id = <> outside selects > (for views), it first "materializes" old layout, and then selects > id... total waste. > > SELECT * FROM (SELECT id, path AS path_a FROM new_table_paths WHERE > pathtype = 'a') AS a NATURAL FULL OUTER JOIN (SELECT id, path AS > path_bb FROM new_table_paths WHERE pathtype = 'bb') AS bb WHERE id = > <>; > > I wonder if you know other way to write this join so it has good performace? > Once again, I need a SELECT since I want a VIEW. :-) Hmm, something like a multiple column returning aggregate... As far as I know it is not possible to create aggregate which could return more than one column? I'm thinking about something like this: SELECT id,r2c_aggregate(pathtype, path) FROM new_table_paths GROUP BY id; ...where r2c_aggregate(..) would be a plpgsql function doing the pathtype+path --> path_a = path, path_bb = path2, path_ccc = path3 assembly. And it would be quite efficient I guess! :) Hmm, r2c_aggregate could return array of arrays of pathtype/path pairs, which could be processed by other function which would convert them into rows, but this is UGLY(TM). :) Regards, Dawid ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
RE RE: [SQL] Single row tables
The first seems like an appropriate solution. Fireing a trigger-function that returns null. If I however try to implement a function getnull in sql I fail. Defining the trigger requests a function of type trigger while definition of a function forbids using trigger as return type. So RTFM - there's however just an example for C. I don't want to engage the compiler :-/ > -Original Message- > From: sad [mailto:[EMAIL PROTECTED] > Sent: Mittwoch, 12. Jänner 2005 07:40 > To: KÖPFERL Robert > Cc: pgsql-sql@postgresql.org > Subject: Re: [SQL] Single row tables > > > On Tuesday 11 January 2005 17:45, KÖPFERL Robert wrote: > > Hi, > > > > with what constraint or how can I ensure that one of my > tables has exact > > one record or 0..1 records? > > A trigger procedure BEFORE INSERT would help you. > > And a column type with only one possible field value would > help you if you > define UNIQUE INDEX on a field of this (user-defined) type. > ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [SQL] Columns into rows.
On Thu, 13 Jan 2005 11:45:52 +0100, Dawid Kuroczko <[EMAIL PROTECTED]> wrote:
> > SELECT * FROM (SELECT id, path AS path_a FROM new_table_paths WHERE
> > pathtype = 'a') AS a NATURAL FULL OUTER JOIN (SELECT id, path AS
> > path_bb FROM new_table_paths WHERE pathtype = 'bb') AS bb WHERE id =
> > <>;
Part of the problem solved:
CREATE AGGREGATE array_aggregate (basetype = anyelement, sfunc =
array_append, stype = anyarray, initcond = '{}');
SELECT id,array_aggregate(pathtype||'='||path) from new_table_paths group by id;
I.e. have a nice array of type=value pairs.
I have however failed to write a function which would take text[] and
return columns. I tried using RETURN record type, but so far it does
not return
anything useful (just a parenthesis enclosed list of column values).
Any hints?
---(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] Syntax error while altering col-type
On Thu, Jan 13, 2005 at 09:48:02AM +0100, KÖPFERL Robert wrote: > I'm a little bit perplexed now... is it really the case that pre 8.0 systems > aren't able to change col-types? It really is. In fact, the feature was (IIRC) somewhat controversial, because there are all sorts of decisions that need to be made about what to do with incompatible types. What if you change from int8 to int4? What about varchar(4) to char(4)? Just to name two simple-minded examples. See the -general and -hackers archives for plenty of previous discussion of this stuff. A -- Andrew Sullivan | [EMAIL PROTECTED] When my information changes, I alter my conclusions. What do you do sir? --attr. John Maynard Keynes ---(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] Syntax error while altering col-type
> > It really is. In fact, the feature was (IIRC) somewhat > controversial, because there are all sorts of decisions that need to > be made about what to do with incompatible types. What if you change > from int8 to int4? What about varchar(4) to char(4)? Just to name > two simple-minded examples. See the -general and -hackers archives > for plenty of previous discussion of this stuff. > but that's the reason, the USING clause exists. It however still remains a problem if triggers, constraints or referential integrity or vews are involved. so far ---(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] Syntax error while altering col-type
On Thu, Jan 13, 2005 at 01:30:21PM +0100, KÖPFERL Robert wrote: > but that's the reason, the USING clause exists. It however still remains a Right. Please see the archives about how this was hammered out. A -- Andrew Sullivan | [EMAIL PROTECTED] A certain description of men are for getting out of debt, yet are against all taxes for raising money to pay it off. --Alexander Hamilton ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[SQL] Column with recycled sequence value
Hi, suppose I have a let's say heavy used table. There's a column containing UNIQUE in4 values. The data type musn't exceed 32-Bit. Since however the table is heavy used 2^32 will be reached soon and then? There are far less than 4G-records saved thus these values may be reused. How can this be accomplished? I already defined a sequence but then? I appreciate your help. ---(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] Column with recycled sequence value
On Thu, Jan 13, 2005 at 06:08:20PM +0100, KÖPFERL Robert wrote: > Hi, > > suppose I have a let's say heavy used table. There's a column containing > UNIQUE in4 > values. The data type musn't exceed 32-Bit. Since however the table is heavy > used 2^32 will be reached soon and then? There are far less than 4G-records > saved thus these values may be reused. How can this be accomplished? You can set the sequence up to cycle (so once it gets to the end, it wraps around to the beginning again). The keyword is CYCLE at CREATE SEQUENCE time. It defaults to NO CYCLE. One potential problem, of course, are collisions on the table, because some value wasn't cleared out. It sounds like you don't have that problem though. A -- Andrew Sullivan | [EMAIL PROTECTED] The plural of anecdote is not data. --Roger Brinner ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [SQL] Column with recycled sequence value
On Thu, Jan 13, 2005 at 18:08:20 +0100, KÖPFERL Robert <[EMAIL PROTECTED]> wrote: > Hi, > > suppose I have a let's say heavy used table. There's a column containing > UNIQUE in4 > values. The data type musn't exceed 32-Bit. Since however the table is heavy > used 2^32 will be reached soon and then? There are far less than 4G-records > saved thus these values may be reused. How can this be accomplished? > > I already defined a sequence but then? It is possible to let sequences roll over. One possible solution is to just try to do inserts with the sequence id and have the application retry when this fails. If the records being kept are almost all recent ones, this should work pretty well. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [SQL] Column with recycled sequence value
On Thu, 2005-01-13 at 11:08, KÃPFERL Robert wrote: > Hi, > > suppose I have a let's say heavy used table. There's a column containing > UNIQUE in4 > values. The data type musn't exceed 32-Bit. Since however the table is heavy > used 2^32 will be reached soon and then? There are far less than 4G-records > saved thus these values may be reused. How can this be accomplished? > > I already defined a sequence but then? Redefine it as a bigserial? ---(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] Column with recycled sequence value
On Thu, Jan 13, 2005 at 02:48:47PM -0600, Scott Marlowe wrote: > On Thu, 2005-01-13 at 11:08, KÖPFERL Robert wrote: > > suppose I have a let's say heavy used table. There's a column containing > > UNIQUE in4 > > values. The data type musn't exceed 32-Bit. Since however the table is heavy > > used 2^32 will be reached soon and then? There are far less than 4G-records > > saved thus these values may be reused. How can this be accomplished? > > > > I already defined a sequence but then? > > Redefine it as a bigserial? That would violate the 32-bit requirement since bigserial would make the field a bigint (64 bits). Or am I missing something? -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [SQL] Column with recycled sequence value
On Thu, 2005-01-13 at 15:19, Michael Fuhr wrote: > On Thu, Jan 13, 2005 at 02:48:47PM -0600, Scott Marlowe wrote: > > On Thu, 2005-01-13 at 11:08, KÃPFERL Robert wrote: > > > > suppose I have a let's say heavy used table. There's a column containing > > > UNIQUE in4 > > > values. The data type musn't exceed 32-Bit. Since however the table is > > > heavy > > > used 2^32 will be reached soon and then? There are far less than > > > 4G-records > > > saved thus these values may be reused. How can this be accomplished? > > > > > > I already defined a sequence but then? > > > > Redefine it as a bigserial? > > That would violate the 32-bit requirement since bigserial would > make the field a bigint (64 bits). Or am I missing something? I wasn't sure if that was a limitation he was facing due to business rules or if he was referring to the limit in postgresql. Any method that tries to reuse sequence numbers is a bad idea (TM) and to be avoided, so my point in asking was if the user didn't know about bigserial / bigint. ---(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
Re: [SQL] Column with recycled sequence value
On Thu, Jan 13, 2005 at 03:31:54PM -0600, Scott Marlowe wrote: > Any method that tries to reuse sequence numbers is a bad idea (TM) and Why? I can think of a dozen cases where it can be useful. It just depends on the application. A -- Andrew Sullivan | [EMAIL PROTECTED] In the future this spectacle of the middle classes shocking the avant- garde will probably become the textbook definition of Postmodernism. --Brad Holland ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [SQL] Column with recycled sequence value
On Thu, Jan 13, 2005 at 03:31:54PM -0600, Scott Marlowe wrote: > > I wasn't sure if that was a limitation he was facing due to business > rules or if he was referring to the limit in postgresql. Gotcha -- I should have asked about the nature of the requirement. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(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
Re: [SQL] Column with recycled sequence value
On Thu, 2005-01-13 at 15:43, Andrew Sullivan wrote: > On Thu, Jan 13, 2005 at 03:31:54PM -0600, Scott Marlowe wrote: > > Any method that tries to reuse sequence numbers is a bad idea (TM) and > > Why? I can think of a dozen cases where it can be useful. It just > depends on the application. The usual, if it's a PK of a FK relationship it's possible to have an orphaned set at some point pointing back to it, race conditions on trying to find a reusable sequence number, and the poor performance needed to lock it to reuse it. What cases are you thinking of? I've seen some very limited ones, like using a short range for managing a queue, but that avoids a lot of the performance issues since it's a small set you're trundling through to find the next one available. But they're not that common, and most of the time someone is thinking of doing so it's because a boss who doesn't get it wants a pretty list with no holes in the sequence or something equally silly. ---(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] Column with recycled sequence value
On Thu, Jan 13, 2005 at 03:57:04PM -0600, Scott Marlowe wrote: > What cases are you thinking of? I've seen some very limited ones, like Off the top of my head - legacy application, closed, where you can't fix the source and can't have larger than 32bit datatype, but you have another way to ensure no dups. - the queue-management item you mentioned. - optimistic cases where a short search range is more important than that a transaction doesn't fail on insert - circular number spaces (xid uses this, after all) > the time someone is thinking of doing so it's because a boss who doesn't > get it wants a pretty list with no holes in the sequence or something > equally silly. Like they have some business problem they need solved, and doing it this way is ugly but relatively cheap, and doing it the other way means replacing 4 software systems and retraining 100 people. Is it a pretty design? Probably not. Is it something that is, of all the compromises available, the best one under the circumstances? I dunno; I'd have to look at the circumstances. I think it's probably usually a good idea to avoid this, sure, but I'm not willing to make it a blanket statement. A -- Andrew Sullivan | [EMAIL PROTECTED] The fact that technology doesn't work is no bar to success in the marketplace. --Philip Greenspun ---(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
Re: [SQL] Column with recycled sequence value
You could update all the fields which use this sequence number. You say you have a lot of activity so you must have mahy holes in your sequence, probably of the possible 2^32 values, only a fes millions are used. You can do the following : - Take down the database, back it up, and restart it with a single user, so only you can connect, using psql. - Create a table : CREATE TABLE translate ( new_id SERIAL PRIMARY KEY, old_id INTEGER, UNIQUE(old_id) ) WITHOUT OIDS; - Insert into this table all the used sequence values you have in your database. If you have all the proper constraints, these should come from only one table, so it should be straightformard : INSERT INTO translate (old_id) SELECT id FROM your_table; Thus the "translate" table maps old id's to a new sequence that you just started, and that means your new id's will be compactly arranged, starting at 1. - Update your existing table, joining it to the translate table, to replace the old id by the new id. On Thu, Jan 13, 2005 at 06:08:20PM +0100, KÖPFERL Robert wrote: Hi, suppose I have a let's say heavy used table. There's a column containing UNIQUE in4 values. The data type musn't exceed 32-Bit. Since however the table is heavy used 2^32 will be reached soon and then? There are far less than 4G-records saved thus these values may be reused. How can this be accomplished? You can set the sequence up to cycle (so once it gets to the end, it wraps around to the beginning again). The keyword is CYCLE at CREATE SEQUENCE time. It defaults to NO CYCLE. One potential problem, of course, are collisions on the table, because some value wasn't cleared out. It sounds like you don't have that problem though. A ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[SQL] pgmirror
Title: pgmirror Hi, I need some help getting dbMirror working. I have installed the contrib RPM package for Redhat Linux. However it hasn't copied all the necessary files for dbMirror. I could only find pending.so. I have tried coping the other files from : http://developer.postgresql.org/docs/pgsql/contrib/dbmirror/ then running the MirrorSetup.sql, however it returned the following error : psql:MirrorSetup.sql:52: ERROR: could not find function "nextval" in file "/usr/lib/pgsql/pending.so" So I assume I need to compile pending.c. I need some help in doing so? Im running RedHat Linux ES3 with Postgres 7.4.5. Regards, Theo __ This email, including attachments, is intended only for the addressee and may be confidential, privileged and subject to copyright. If you have received this email in error, please advise the sender and delete it. If you are not the intended recipient of this email, you must not use, copy or disclose its content to anyone. You must not copy or communicate to others content that is confidential or subject to copyright, unless you have the consent of the content owner.
Re: [SQL] Column with recycled sequence value
Andrew Sullivan <[EMAIL PROTECTED]> writes: > You can set the sequence up to cycle (so once it gets to the end, it > wraps around to the beginning again). The keyword is CYCLE at CREATE > SEQUENCE time. It defaults to NO CYCLE. > > One potential problem, of course, are collisions on the table, > because some value wasn't cleared out. It sounds like you don't have > that problem though. Alternatively you can go through the database and make sure all the foreign keys are declared and marked ON UPDATE CASCADE. Then go through and renumber all your entries sequentially starting at 1 and reset your sequence. I'm not sure this is such a hot idea really. But I don't really like the idea of letting the sequence wrap around much either. You'll have to consider the pros and cons of each approach (and of just moving to bigserial too). If you're going to do this you'll want an index on all the foreign key columns. That is, the columns referring to this value from other tables. Otherwise the automatic updates would be very slow. And will probably want to schedule down-time for this. Otherwise application code that holds values in local state might get very confused. I think I would do it with a program that connects and updates each record individually and commits periodically rather than with a single big update. Just because I like having control and having things that give me progress information and can be interrupted without losing work. Oh, and this won't work if you have any external references to these values from outside your database. Say if the value is something like a customer account number that you've previously sent to customers... -- greg ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
