Re: [GENERAL] [HACKERS] money with 4 digits after dot
I found a workaround: domain type defined as: CREATE DOMAIN currency AS numeric(16,4); Thank you!
Re: [GENERAL] bloating index, pg_restore
Sergey Konoplev writes: > On Wed, Mar 27, 2013 at 9:56 AM, salah jubeh wrote: >> I have a database which is bloated because of vacuum full, so you find >> indexes bigger than the table itself. > Table can not be bloated because of vacuum full, it removes bloat from > the table and its indexes. Um, well, that depends a lot on which PG version the OP is running (which he didn't say). The pre-9.0 implementation of VACUUM FULL was notorious for creating index bloat, because it shuffled heap entries around to compact heap space, but created an additional index entry for each such heap-tuple motion. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] bloating index, pg_restore
Hello, On Wed, Mar 27, 2013 at 9:56 AM, salah jubeh wrote: > I have a database which is bloated because of vacuum full, so you find > indexes bigger than the table itself. Table can not be bloated because of vacuum full, it removes bloat from the table and its indexes. The fact that an index is larger then the table it it built on does not say that something is bloated. Use the pgstattuple extension to determine bloat http://www.postgresql.org/docs/9.2/static/pgstattuple.html. > I have dumped this database and restored it without reindixing and it was > extremely slow. So, my question what is the relation between bloated > database and pg_restore. > > Regards -- Kind regards, Sergey Konoplev Database and Software Consultant Profile: http://www.linkedin.com/in/grayhemp Phone: USA +1 (415) 867-9984, Russia +7 (901) 903-0499, +7 (988) 888-1979 Skype: gray-hemp Jabber: gray...@gmail.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Is there any way to listen to NOTIFY in php without polling?
Hi Misa > But Example shows - that C app - actually asks all the time to get notify... > when gets something more then 4 times - exit... until 4 times loops... > The same you can achieve with PHP... As far as I understood, with php I have to query the server again and again, and pg_get_notify will either return something or not depending on the query result: http://php.net/manual/en/function.pg-get-notify.php The provided sample however blocks until a notify is received (and does so 4 times just for demonstration puporse), so instead of frequently asking the server for notifications (polling), it wakes up when a notification arrives. > My guess is that main goal is let Web App know - something happened in > database... It isn't ;) Regards, Clemens -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Money casting too liberal?
In contrast to certain other open-source databases, PostgreSQL leans toward protecting data from surprises and erroneous input, i.e. rejecting a date of 2013-02-31 instead of arbitrarily assigning a date of 2013-03-03. Similar "throw error" instead of "take a guess" philosophy applies to numeric and string operations as well. It's an approach I appreciate. But it appears that the philosophy does not extend to the "money" type. Although there are certain checks including no alpha, '$' and '-', if present, must be in the first two characters of the string and commas can't be at the end. Otherwise the casting is fairly liberal. Commas, for instance, can appear nearly anywhere including after the decimal point: select ',123,456,,7,8.1,0,9'::money; money $12,345,678.11 Somewhat more worrisome is the fact that it automatically rounds input (away from zero) to fit. select '123.456789'::money; money - $123.46 select '$-123.456789'::money; money -- -$123.46 Thoughts? Is this the "no surprises" way that money input should behave? Cheers, Steve -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Is there any way to listen to NOTIFY in php without polling?
Hi Clemens, Well, I am not sure what you mean by polling... But Example shows - that C app - actually asks all the time to get notify... when gets something more then 4 times - exit... until 4 times loops... The same you can achieve with PHP... But I am not sure that is the main goal... My guess is that main goal is let Web App know - something happened in database... I am not aware about something else in JDBC then the same principle... One object (listner) - in background thread - always asks for notify DB - if gets something - fires event... (then other Java objects - if subscribed on Listner - do whatever need to doon that event) If we want - to let WebPage aware about what happened - still we are in the problem... (if we will not use - some kind of polling from WebPage) Potential Solution: websocket The same solution would be possible and with php... But better to dont make this mail more complex - if that is not the goal... :) Kind Regards, Misa 2013/3/27 Clemens Eisserer > Hi Misa > > > What is the main goal? > > The main goal is to perform some inter-system communication in the > case some rows in one table are updated (very seldom event). > > > even using libpg - you need to call pg notify... Doc says, just using > > libpgtcl would be possible to get Notify event - without checking from > time > > to time... > > I found example 27-2 at > http://www.postgresql.org/docs/8.0/static/libpq-example.html , that > does exactly what I was looking for using low-level socket functions. > It seems to me this solution works without polling. > > Regards, Clemens > > PS: Compared to the libpq and php interfaces, the jdbc driver does a > really good job providing a useable interface for listen/notify to the > developers. Thanks :) > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general >
Re: [GENERAL] Is there any way to listen to NOTIFY in php without polling?
Hi Misa > What is the main goal? The main goal is to perform some inter-system communication in the case some rows in one table are updated (very seldom event). > even using libpg - you need to call pg notify... Doc says, just using > libpgtcl would be possible to get Notify event - without checking from time > to time... I found example 27-2 at http://www.postgresql.org/docs/8.0/static/libpq-example.html , that does exactly what I was looking for using low-level socket functions. It seems to me this solution works without polling. Regards, Clemens PS: Compared to the libpq and php interfaces, the jdbc driver does a really good job providing a useable interface for listen/notify to the developers. Thanks :) -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Is there any way to listen to NOTIFY in php without polling?
Hi, What is the main goal? even using libpg - you need to call pg notify... Doc says, just using libpgtcl would be possible to get Notify event - without checking from time to time... Kind Regards, Misa 2013/3/27 Clemens Eisserer > Hi Bill, > > >> Is there any way to listen to NOTIFY in php without polling using a > >> callback or blocking call? > > > > Not at this time. > > Too bad ... Thanks for the confirmation. > > I'll try to invoke a native libpg binary which stays alive until a > NOTIFY is received, should do the trick in case update-frequency is > low. > > Thanks, Clemens > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general >
Re: [GENERAL] Is there any way to listen to NOTIFY in php without polling?
Hi Bill, >> Is there any way to listen to NOTIFY in php without polling using a >> callback or blocking call? > > Not at this time. Too bad ... Thanks for the confirmation. I'll try to invoke a native libpg binary which stays alive until a NOTIFY is received, should do the trick in case update-frequency is low. Thanks, Clemens -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Is there any way to listen to NOTIFY in php without polling?
In response to Clemens Eisserer : > > Is there any way to listen to NOTIFY in php without polling using a > callback or blocking call? Not at this time. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Is there any way to listen to NOTIFY in php without polling?
Hi, Sorry for asking such a newbie-question, I've used a search engine - however I haven't found what I am searching for. Is there any way to listen to NOTIFY in php without polling using a callback or blocking call? I've only found pg_get_notify(), however it requires polling as far as I understand. Thank you in advance, Clemens -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] bloating index, pg_restore
Hello, I have a database which is bloated because of vacuum full, so you find indexes bigger than the table itself. I have dumped this database and restored it without reindixing and it was extremely slow. So, my question what is the relation between bloated database and pg_restore. Regards
Re: [GENERAL] pltcl and modules question
>> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: RIPEMD160 >> >> >> > is there any way to use a module within a pltcl script, i.e. have >> > load /path/to/mystuff.so >> > or >> > package require mystuff >> > in a script. >> >> You can load tcl code by putting it in the pltcl_modules tables. See: >> >> http://www.postgresql.org/docs/9.2/static/pltcl-unknown.html >> >> > Similarly, would it be possible to access loaded module from perl >> > script, i.e. have >> > use mystuff; >> >> You can load any Perl module you want within a Pl/PerlU function. >> >> It's possible to access shared code with Pl/Perl, but it's a little >> more involved. See: >> >> http://www.postgresql.org/docs/9.2/static/plperl-under-the-hood.html >> >> - -- Hi Greg, thanks a lot, I will give it a try next week. Comparing the two references, I sort of fear that there mght be a problem when tcl wants to load a binary rather than script module I can try pgtclu as well Regards Wolfgang Hamann -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why does Postgres allow duplicate (FK) constraints
Thomas Kellerer wrote: > Alban Hertroys, 26.03.2013 17:17: >> It can make sense during a maintenance window, if you create a new >> (redundant) FK constraint concurrently to replace the existing one. >> If you'd first remove the existing constraint, you're allowing FK >> violations until the new constraint has finished creating its index. >> >> This happens for example if you want to use a different index >> algorithm, say a gist index instead of a btree index, or if the >> initial index has gotten corrupt somehow and it needs reindexing. > > I can understand this for indexes, but a foreign key constraint does not > create > one. I once saw a case where this needed to be done because the dependency information somehow became inconsistent. -- Kevin Grittner EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Understanding behavior of SELECT with multiple unnested columns
2013/3/27 Tom Lane : > Gavin Flower writes: >> The rule appears to be, >> where N_x & N_y are the number of entries returned for x & y: >> N_result = is the smallest positive integer that has N_x & N_y as factors. > > Right: if there are multiple set-returning functions in a SELECT list, > the number of rows you get is the least common multiple of their > periods. (See the logic in ExecTargetList that cycles the SRFs until > they all report "done" at the same time.) I guess there's some value > in this for the case where they all have the same period, but otherwise > it's kind of bizarre. It's been like that since Berkeley days though, > so I doubt we'll consider changing it now. Rather, it'll just be > quietly deprecated in favor of putting SRFs into FROM (with LATERAL > where needed). Thanks for the clarification, I was half-worried there was some fundamental set theory or something which had passed me by. Regards Ian Barwick -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pg_stat_get_last_vacuum_time(): why non-FULL?
On 2013-03-26 19:28, Kevin Grittner wrote: >> Why are full vacuums excluded from this statistic? It looks like there's >> no way to get the date of the last manual vacuum, if only full vacuums >> are performed. > > Because FULL is a bit of a misnomer -- there are important things a > non-FULL vacuum does which a FULL vacuum does not. In general, a > VACUUM FULL should be followed by a non-FULL vacuum to keep the > database in good shape. Thank you, that's very helpful. I wasn't aware of that. > Also, a VACUUM FULL is an extreme form of > maintenance which should rarely be needed; if you find that you > need to run VACUUM FULL, something is probably being done wrong > which should be fixed so that you don't need to continue to do such > extreme maintenance. In this case I was only trying to make sense of an existing database (8.3). The statistics in pg_stats were way off for some tables, so I wanted to see if (auto)vacuum and (auto)analyze were being run. pg_stat_all_tables() showed last_autoanalyze at >400 days for some of the larger tables. There used to be a weekly cron job with VACUUM FULL ANALYZE, and I was trying to find out if that cron job was still active. Thanks, crl -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pltcl and modules question
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > is there any way to use a module within a pltcl script, i.e. have > load /path/to/mystuff.so > or > package require mystuff > in a script. You can load tcl code by putting it in the pltcl_modules tables. See: http://www.postgresql.org/docs/9.2/static/pltcl-unknown.html > Similarly, would it be possible to access loaded module from perl > script, i.e. have > use mystuff; You can load any Perl module you want within a Pl/PerlU function. It's possible to access shared code with Pl/Perl, but it's a little more involved. See: http://www.postgresql.org/docs/9.2/static/plperl-under-the-hood.html - -- Greg Sabino Mullane g...@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201303271036 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAlFTBHcACgkQvJuQZxSWSsiDogCdHga7xxBEVJFSEKlJqME+uo0o pykAnicK1fLKZOJZMN2j1iEKQr4+AQMk =b3/1 -END PGP SIGNATURE- -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Understanding behavior of SELECT with multiple unnested columns
Gavin Flower writes: > The rule appears to be, > where N_x & N_y are the number of entries returned for x & y: > N_result = is the smallest positive integer that has N_x & N_y as factors. Right: if there are multiple set-returning functions in a SELECT list, the number of rows you get is the least common multiple of their periods. (See the logic in ExecTargetList that cycles the SRFs until they all report "done" at the same time.) I guess there's some value in this for the case where they all have the same period, but otherwise it's kind of bizarre. It's been like that since Berkeley days though, so I doubt we'll consider changing it now. Rather, it'll just be quietly deprecated in favor of putting SRFs into FROM (with LATERAL where needed). regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why does Postgres allow duplicate (FK) constraints
Alban Hertroys, 26.03.2013 17:17: It can make sense during a maintenance window, if you create a new (redundant) FK constraint concurrently to replace the existing one. If you'd first remove the existing constraint, you're allowing FK violations until the new constraint has finished creating its index. This happens for example if you want to use a different index algorithm, say a gist index instead of a btree index, or if the initial index has gotten corrupt somehow and it needs reindexing. I can understand this for indexes, but a foreign key constraint does not create one. Regards Thomas -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Why does Postgres allow duplicate (FK) constraints
Tom Lane, 26.03.2013 17:16: The lack of any prohibition to the contrary means there is no way to argue that the code you showed previously violates the spec; thus, a database that fails to accept it is rejecting spec-compliant DDL. I'm not claiming that the spec is violated... (And I'm not complaining either. I'm just curious if there was a technical reason) Well, it's redundant, but that doesn't make it wrong. In any case, there are lots of ways that things might be redundant. Should we reject a unique constraint on (a,b) if there's already one on (b,a)? Or if there are separate unique constraints on each of a and b? Hmm, good point. Although I think a definition that is identical with regards of the columns and their position in the constraint _could_ be considered identical. Anyway thanks for the feedback. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Understanding behavior of SELECT with multiple unnested columns
Hi, You can try: SELECT c1, c2 FROM ( WITH a AS ( SELECT row_number() OVER(),* FROM unnest(array['a','b', 'c', 'd']) c1 ), b AS ( SELECT row_number() OVER(),* FROM unnest(array['1','2', '3']) c2 ) SELECT * FROM a LEFT JOIN b USING (row_number) UNION SELECT * FROM a RIGHT JOIN b USING (row_number) ORDER BY row_number ) t To simplify this you can wrap it in function what accepts two array parameters... Kind Regards, Misa 2013/3/27 Ken Tanzer > I've been working on some queries involving multiple unnested columns. At > first, I expected the number of rows returned would be the product of the > array lengths, so that this query would return 4 rows: > > SELECT unnest2(array['a','b']),unnest2(array['1','2']); > > when in fact it returns 2: > > unnest2 | unnest2 > -+- > a | 1 > b | 2 > > Which is all well and good. (Better, in fact, for my purposes.) But > then this query returns 6 rows: > > SELECT unnest2(array['a','b','c']),unnest2(array['1','2']); > unnest2 | unnest2 > -+- > a | 1 > b | 2 > c | 1 > a | 2 > b | 1 > c | 2 > > Throw an unnested null column in and you get zero rows, which I also > didn't expect: > > SELECT > unnest2(array['a','b','c']),unnest2(array['1','2']),unnest(NULL::varchar[]); > unnest2 | unnest2 | unnest > -+-+ > (0 rows) > > > After some head scratching, I think I understand what to expect from these > unnests, but I'm unclear of the logic behind what is going on. I'm hoping > someone can explain it a bit. Also, on a practical level, would anyone > know how to query so that SELECT > unnest2(array['a','b','c']),unnest2(array['1','2']) would return three rows > instead of six, like so: > > a 1 > b 2 > c (NULL) > > As that would be perfect for my purposes. Thanks in advance! > > Ken > > > > > -- > AGENCY Software > A data system that puts you in control > 100% Free Software > *http://agency-software.org/* > ken.tan...@agency-software.org > (253) 245-3801 > > Subscribe to the mailing > list > to > learn more about AGENCY or > follow the discussion. >
Re: [GENERAL] Understanding behavior of SELECT with multiple unnested columns
On 27/03/13 20:36, Ian Lawrence Barwick wrote: 2013/3/27 Ken Tanzer mailto:ken.tan...@gmail.com>> Basically you are getting Cartesian joins on the row output of unnest() Well that's what I expected too. Except look at this example, after you delete c: testdb=# DELETE FROM t2 where val='c'; DELETE 1 testdb=# SELECT * from t1, t2; val | val -+- 1 | a 1 | b 2 | a 2 | b (4 rows) And compare to: SELECT unnest(array[1,2]),unnest(array['a','b']); unnest | unnest + 1 | a 2 | b (2 rows) You can see they are not the same! Ah yes, what I suggested is actually the equivalent to SELECT * FROM unnest(array[1,2]) u1,unnest(array['a','b']) u2; I seem to recall seeing the explanation for this before, although I'll be darned if I can remember what it is. FWIW this happens with other functions returning SETOF: testdb=# SELECT testdb-# generate_series(1,2) x, testdb-# generate_series(1,2) y; x | y ---+--- 1 | 1 2 | 2 (2 rows) testdb=# SELECT testdb-# generate_series(1,2) x, testdb-# generate_series(1,3) y; x | y ---+--- 1 | 1 2 | 2 1 | 3 2 | 1 1 | 2 2 | 3 (6 rows) Regards Ian Barwick The rule appears to be, where N_x & N_y are the number of entries returned for x & y: N_result = is the smallest positive integer that has N_x & N_y as factors. Cheers, Gavin
Re: [GENERAL] Understanding behavior of SELECT with multiple unnested columns
2013/3/27 Ken Tanzer > Basically you are getting Cartesian joins on the row output of >> unnest() > > > Well that's what I expected too. Except look at this example, after you > delete c: > > testdb=# DELETE FROM t2 where val='c'; > DELETE 1 > testdb=# SELECT * from t1, t2; > val | val > -+- >1 | a >1 | b >2 | a >2 | b > (4 rows) > > And compare to: > > SELECT unnest(array[1,2]),unnest(array['a','b']); > unnest | unnest > + > 1 | a > 2 | b > (2 rows) > > You can see they are not the same! > Ah yes, what I suggested is actually the equivalent to SELECT * FROM unnest(array[1,2]) u1,unnest(array['a','b']) u2; I seem to recall seeing the explanation for this before, although I'll be darned if I can remember what it is. FWIW this happens with other functions returning SETOF: testdb=# SELECT testdb-# generate_series(1,2) x, testdb-# generate_series(1,2) y; x | y ---+--- 1 | 1 2 | 2 (2 rows) testdb=# SELECT testdb-# generate_series(1,2) x, testdb-# generate_series(1,3) y; x | y ---+--- 1 | 1 2 | 2 1 | 3 2 | 1 1 | 2 2 | 3 (6 rows) Regards Ian Barwick
Re: [GENERAL] Understanding behavior of SELECT with multiple unnested columns
>
> Basically you are getting Cartesian joins on the row output of
> unnest()
Well that's what I expected too. Except look at this example, after you
delete c:
testdb=# DELETE FROM t2 where val='c';
DELETE 1
testdb=# SELECT * from t1, t2;
val | val
-+-
1 | a
1 | b
2 | a
2 | b
(4 rows)
And compare to:
SELECT unnest(array[1,2]),unnest(array['a','b']);
unnest | unnest
+
1 | a
2 | b
(2 rows)
You can see they are not the same! Or this, which does not return the 12
rows we might both expect:
SELECT unnest(array[1,2]),unnest(array['a','b']),unnest(array[4,5,6]);
unnest | unnest | unnest
++
1 | a | 4
2 | b | 5
1 | a | 6
2 | b | 4
1 | a | 5
2 | b | 6
(6 rows)
Add another element onto the third array, so they "match up" better, and
you get only 4 rows:
SELECT unnest(array[1,2]),unnest(array['a','b']),unnest(array[4,5,6,7]);
unnest | unnest | unnest
++
1 | a | 4
2 | b | 5
1 | a | 6
2 | b | 7
(4 rows)
(and presumably
> unnest2() - I guess this is a function you defined yourself?)
Sorry for causing confusion--I meant to remove the unnest2. There was
source code for the unnest function for earlier versions, which I defined
as unnest2 to try to understand what was going on. It should yield the
same behavior as unnest itself.
Cheers,
Ken
On Tue, Mar 26, 2013 at 11:55 PM, Ian Lawrence Barwick wrote:
> 2013/3/27 Ken Tanzer
> >
> > I've been working on some queries involving multiple unnested columns.
> At first, I expected the number of rows returned would be the product of
> the array lengths, so that this query would return 4 rows:
> >
> > SELECT unnest2(array['a','b']),unnest2(array['1','2']);
> >
> > when in fact it returns 2:
> >
> > unnest2 | unnest2
> > -+-
> > a | 1
> > b | 2
> >
> > Which is all well and good. (Better, in fact, for my purposes.) But
> then this query returns 6 rows:
> >
> > SELECT unnest2(array['a','b','c']),unnest2(array['1','2']);
> > unnest2 | unnest2
> > -+-
> > a | 1
> > b | 2
> > c | 1
> > a | 2
> > b | 1
> > c | 2
> >
> > Throw an unnested null column in and you get zero rows, which I also
> didn't expect:
> >
> > SELECT
> unnest2(array['a','b','c']),unnest2(array['1','2']),unnest(NULL::varchar[]);
> > unnest2 | unnest2 | unnest
> > -+-+
> > (0 rows)
> >
> >
> > After some head scratching, I think I understand what to expect from
> these unnests, but I'm unclear of the logic behind what is going on. I'm
> hoping someone can explain it a bit.
>
> Basically you are getting Cartesian joins on the row output of
> unnest() (and presumably
> unnest2() - I guess this is a function you defined yourself?)
>
> Effectively you are doing this:
>
> CREATE TABLE t1 (val INT);
> INSERT INTO t1 VALUES (1),(2);
>
> CREATE TABLE t2 (val CHAR(1));
> INSERT INTO t2 VALUES ('a'),('b'),('c');
>
> CREATE TABLE t3 (val INT);
>
> testdb=# SELECT * from t1, t2;
> val | val
> -+-
>1 | a
>1 | b
>1 | c
>2 | a
>2 | b
>2 | c
> (6 rows)
>
>
> testdb=# DELETE FROM t2 where val='c';
> DELETE 1
> testdb=# SELECT * from t1, t2;
> val | val
> -+-
>1 | a
>1 | b
>2 | a
>2 | b
> (4 rows)
>
> testdb=# SELECT * from t1, t2, t3;
> val | val | val
> -+-+-
> (0 rows)
>
>
> HTH
>
> Ian Barwick
>
--
AGENCY Software
A data system that puts you in control
100% Free Software
*http://agency-software.org/*
ken.tan...@agency-software.org
(253) 245-3801
Subscribe to the mailing
list
to
learn more about AGENCY or
follow the discussion.
