[HACKERS] inquiery
hello what is RIR rules in Rewriter? What RIR means? Thank you very much. Jinqiang Han ---(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: [HACKERS] request for sql3 compliance for the update command
Bruce Momjian kirjutas E, 17.03.2003 kell 20:49: With no one replying on how to do correlated subqueries in FROM for UPDATE, Correlated subqueries not working in FROM cluse of UPDATE is IMHO a bug, so the way to do correlated subqueries in FROM for UPDATE would be to fix this bug ;) All common sense tells me that if I can update set col1=col2 and *not* get the value from the first col2 to all col1's then the same should be true for this hannu=# creatre table updtarget( hannu(# id int, val text); ERROR: parser: parse error at or near creatre at character 1 hannu=# create table updtarget(id int, val text); CREATE TABLE hannu=# create table updsource(id int, val text); CREATE TABLE hannu=# insert into updtarget(id) values (1); INSERT 16995 1 hannu=# insert into updtarget(id) values (2); INSERT 16996 1 hannu=# insert into updsource(id,val) values (1,'one'); INSERT 16997 1 hannu=# insert into updsource(id,val) values (2,'two'); INSERT 16998 1 hannu=# update updtarget set val = src.val hannu-# from (select s.val from updsource s hannu-#where s.id=updtarget.id) as src hannu-# ; NOTICE: Adding missing FROM-clause entry in subquery for table updtarget UPDATE 2 hannu=# select * from updtarget; id | val +- 1 | one 2 | one (2 rows) there should be no need to add missing FROM-clause entry and the result *should* be: hannu=# select * from updtarget; id | val +- 1 | one 2 | two (2 rows) Hannu ---(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] Mail problem
I'm having a problem with my postgresql email. I cannot access my imap account on postgresql.org anymore. For two or three days now no mail to [EMAIL PROTECTED] has made it to me. And I wasn't able to conatct Marc so far. The account is there as I can login via ssh. So if you want to contact me, feel free to use my [EMAIL PROTECTED] address. Michael -- Michael Meskes Email: [EMAIL PROTECTED] ICQ: 179140304 Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Another naive question, inheritance and foreign key
Hi,
Just stumbled upon this. Is it correct to conclude that foreign keys are not
inherited from this text?
phd=# create table perbookings(type smallint) inherits (bookings);
CREATE TABLE
phd=# \d perbookings;
Table public.perbookings
Column |Type |Modifiers
+-+--
rid| integer |
uid| integer |
stime | timestamp without time zone |
etime | timestamp without time zone |
bid| integer | default nextval('bid_seq'::text)
type | smallint|
Check constraints: bookings_etime (etime stime)
phd=# \d bookings;
Table public.bookings
Column |Type |Modifiers
+-+--
rid| integer |
uid| integer |
stime | timestamp without time zone |
etime | timestamp without time zone |
bid| integer | default nextval('bid_seq'::text)
Check constraints: bookings_etime (etime stime)
Foreign Key constraints: $1 FOREIGN KEY (rid) REFERENCES resource(id) ON
UPDATE CASCADE ON DELETE CASCADE,
$2 FOREIGN KEY (uid) REFERENCES users(userid) ON
UPDATE CASCADE ON DELETE CASCADE
phd=# select version();
version
-
PostgreSQL 7.3.2 on i386-portbld-freebsd4.7, compiled by GCC 2.95.4
(1 row)
TIA..
Shridhar
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] request for sql3 compliance for the update command
Tom Lane kirjutas K, 19.03.2003 kell 16:46: Bruce Momjian [EMAIL PROTECTED] writes: I wasn't sure it made logical sense to allow correlated subqueries in FROM because the FROM is processed before the WHERE. It doesn't; in fact it violates the whole semantic model of SQL, as far as I can see. Sub-selects in FROM are (in principle) evaluated separately and then joined. They can't have cross-references. Makes sense. What I was describing would have been akin to updatable queries where you first do all the joining and then update one of the underlying tables. the more accurate (nonstandard) syntax could have been SELECT src.val, tgt.val FROM updatesrc as src FOR UPDATE, updatetgd as tgt WHERE src.id = tgt.id SET src.val = tgt.val ; I think there is some weird construct in SQL99 that alters this behavior, though. You probably mean WITH, which acts like FROM but has lexically previous (or all in case of WITH RECURSIVE) sub-selects in its namespace. Hannu ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Another naive question, inheritance and foreign key
On Wed, 19 Mar 2003, Shridhar Daithankar[EMAIL PROTECTED] wrote: Just stumbled upon this. Is it correct to conclude that foreign keys are not inherited from this text? Yes. If you want more info, check out the archives. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Nested transactions: low level stuff
Manfred Koizar [EMAIL PROTECTED] writes: If we set XMIN/MAX_IS_COMMITTED in a tuple header, we have to replace a sub-transaction xid in xmin or xmax respectively with the main-transaction xid at the same time. Otherwise we'd have to look for the main xid, whenever a tuple is touched. This worries me --- it changes a safe operation (OR'ing in a commit bit) into an unsafe one that requires exclusive lock on the page containing the tuple. I'm also concerned that we'd now need a WAL entry to record the xid change (are we dependent on this change occurring for correctness? or is it only performance?) Perhaps it would be better to leave the tuple-commit bit unset until we have been able to change the clog state to 01 (committed to everyone). Tom: I think it would be preferable to use only three states: active, aborted, committed. Con: Needs subtrans tree navigation from parent to child. But only in the backend owning the transaction; there's no need for shared state that allows it. Sorry for the long post. Would you prefer such kind of stuff on a web page and just a short note with the URL to the list? No. This way it gets into the list archives. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] A bad behavior under autocommit off mode
OK, I have a patch to fix this bug. The basic problem is that when a
multi-query string is passed to the backend, it is treated as a single
transaction _unless_ a transaction or GUC command appears in the string.
When they appear, a transaction is forced, but the normal transaction
state machine has been bypassed, meaning in:
SET autocommit TO off; SELECT 1; COMMIT;
when the COMMIT arrives, the transaction state machines hasn't seen the
SELECT because the mechanism is bypassing the state machine to try and
get everything into the same transaction.
This patch removes that stuff all queries into a single transaction
behavior and makes them function just like queries arriving separately.
This does BREAK BACKWARD COMPATIBILITY. However, if they want the old
behavior, they just need to wrap BEGIN/COMMIT around the query string.
I could have fixed it with a hack to the transaction state machine, but
this seems like the proper fix. I never liked that single-transaction
query string behavior anyway. It seemed too strange.
---
Hiroshi Inoue wrote:
Hi all,
There seems a bad behavior under autocommit off mode.
1) psql -c 'set autocommit to off;select 1;commit'
causes a WARNING: COMMIT: no transaction in progress
whereas
2) psql -c 'begin;select 1;commit'
causes no error/warning.
Note that the result is the same even when you issue
the first set/begin command separately using the client
softwares other than psql.
The problem here is that the transaction is cancelled
in case of 1) though no error is reported.
Shouldn't we avoid the warning and the cancellation ?
Or should an error be reported instead of the warning ?
regards,
Hiroshi Inoue
http://www.geocities.jp/inocchichichi/psqlodbc/
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
--
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
Index: src/backend/tcop/postgres.c
===
RCS file: /cvsroot/pgsql-server/src/backend/tcop/postgres.c,v
retrieving revision 1.317
diff -c -c -r1.317 postgres.c
*** src/backend/tcop/postgres.c 10 Mar 2003 03:53:51 - 1.317
--- src/backend/tcop/postgres.c 19 Mar 2003 16:54:53 -
***
*** 880,899
finish_xact_command(true);
xact_started = false;
}
! } /* end loop over
queries generated from a
!* parsetree */
! /*
!* If this is the last parsetree of the query string, close down
!* transaction statement before reporting command-complete. This
!* is so that any end-of-transaction errors are reported before
!* the command-complete message is issued, to avoid confusing
!* clients who will expect either a command-complete message or an
!* error, not one and then the other. But for compatibility with
!* historical Postgres behavior, we do not force a transaction
!* boundary between queries appearing in a single query string.
!*/
! if (lnext(parsetree_item) == NIL xact_started)
{
finish_xact_command(false);
xact_started = false;
--- 880,888
finish_xact_command(true);
xact_started = false;
}
! } /* end loop over queries generated from a parsetree */
! if (xact_started)
{
finish_xact_command(false);
xact_started = false;
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Nested transactions: low level stuff
On Wed, 19 Mar 2003 11:18:38 -0500, Tom Lane [EMAIL PROTECTED] wrote: Manfred Koizar [EMAIL PROTECTED] writes: If we set XMIN/MAX_IS_COMMITTED in a tuple header, we have to replace a sub-transaction xid in xmin or xmax respectively with the main-transaction xid at the same time. Otherwise we'd have to look for the main xid, whenever a tuple is touched. This worries me --- it changes a safe operation (OR'ing in a commit bit) into an unsafe one that requires exclusive lock on the page containing the tuple. [Only talking about xmin here, but everything refers to xmax as well.] I was hoping we could set xmin atomically without holding a lock. If we can, we first set xmin to the main xid. The new state is still consistent; now it looks as if the change has been made directly by the main transaction and not by one of its subtransactions, which is ok after the main transaction has committed (we are only talking about cases where all interesting transactions have committed). As a second step we update the commit bit which is as safe as it is now. I see no concurrency problems. If two or more backends visit the same tuple, they either write the same value to the same position which doesn't hurt, or one sees the other's changes which is a good thing. So this boils down to whether setting the value of a properly aligned 32 bit variable in shared memory is an atomic operation on all supported platforms. I don't know enough about compilers to answer this question. I'm also concerned that we'd now need a WAL entry to record the xid change If the sequence is first update xmin, then set the commit bit, we never have an inconsistent state. And if the change is lost, it can be redone by the next backend visiting the tuple. So I think we don't need a WAL entry. (are we dependent on this change occurring for correctness? or is it only performance?) The latter. Perhaps it would be better to leave the tuple-commit bit unset until we have been able to change the clog state to 01 (committed to everyone). At least we can fall back to this, if we can't find out how to update the xid safely. Servus Manfred ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Nested transactions: low level stuff
Manfred Koizar [EMAIL PROTECTED] writes: If the sequence is first update xmin, then set the commit bit, we never have an inconsistent state. And if the change is lost, it can be redone by the next backend visiting the tuple. Not if the subtransaction log state has been removed as no longer needed. I think a WAL entry will be essential. (An alternative might be to keep subtransaction state as long as we keep pg_clog state, but that's pretty unpleasant too.) I think we'd be a lot better off to design this so that we don't need to alter heap tuple xmin values... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Nested transactions: low level stuff
I see no concurrency problems. If two or more backends visit the same tuple, they either write the same value to the same position which doesn't hurt, or one sees the other's changes which is a good thing. AFAIR, on multi-CPU platforms it's possible that second transaction could see COMMITTED state but still old (subtrans id) in xmin: it's not guaranteed that changes made on CPU1 (V1 was changed first, then V2 was changed) will appear at the same order on CPU2 (V2 may come first, then V1). Vadim _ Revere Data, LLC, formerly known as Sector Data, LLC, is not affiliated with Sector, Inc., or SIAC. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Nested transactions: low level stuff
On Wed, 19 Mar 2003 13:00:07 -0500, Tom Lane [EMAIL PROTECTED] wrote: Manfred Koizar [EMAIL PROTECTED] writes: And if the change is lost, it can be redone by the next backend visiting the tuple. Not if the subtransaction log state has been removed as no longer needed. But this problem is not triggered by a tuple that has its xmin changed by a visitor and then looses that change again. We'd have the same problems with tuples that have never been visited (*). So we must make sure that pg_subtrans segments are not discarded as long as they are needed. (*) I guess your argument is: VACUUM makes sure that all tuples have been visited before it discards pg_subtrans segments. With my 4-state-proposal VACUUM can decide whether a pg_subtrans segment is still needed by only looking at pg_clog. I think a WAL entry will be essential. I'm still in doubt, but it's moot (see below). I think we'd be a lot better off to design this so that we don't need to alter heap tuple xmin values... If Vadim remembers correctly we cannot safely change xmin, unless we want to grab a write lock. Ok, we'll not change xmin and we'll not set the commit bit before xmin is visible to all if xmin is a subtransaction. We can always add this performance hack later, if someone finds a safe implementation ... Servus Manfred ---(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] Change for multiple queries in a string
To improve handling of autocommit off mode, I am proposing a change in our next release. Right now, if you pass multiple queries in the same string to the backend: psql -c 'INSERT INTO test VALUES (1);INSERT INTO test VALUES (2); template1 the query is considered to be a single transaction. (Of course, this doesn't make a lot of sense, but historically, this is how PostgreSQL has behaved.) This causes confusion with autocommit off (and probably confuses users too): psql -c 'SET autocommit TO off;SELECT 1;COMMIT template1 Right now, this will generate an error because of the hack used to get everything in a single transaction. In our next release, this will work fine, and sending multiple queries in a single string will be treated as though each command was issued singly. If you need the old behavior, you need to use BEGIN/COMMIT around you query: psql -c 'BEGIN; INSERT INTO test VALUES (1);INSERT INTO test VALUES (2);COMMIT; template1 (Psql already automatically breaks up queries passed on stdin.) Is this OK with everyone? -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Yet another configuration patch with include, and configuration
mlw, would you modify this to use the config_path idea we agreed upon so
we can get this into 7.4?
---
mlw wrote:
This is a patch that allows PostgreSQL to use a configuration
file that is outside the main database directory.
It adds one more command line parameter, -C which
specifies either the location of the postgres configuration
file or a directory containing the configuration files.
A patched version of PostgreSQL will function as:
--- Configuration file ---
postmaster -C /etc/postgres/postgresql.conf
This will direct the postmaster program to use the
configuration file /etc/postgres/postgresql.conf
--- Configuration Directory ---
postmaster -C /etc/postgres
This will direct the postmaster program to search the
directory /etc/postgres for the standard configuration
file names: posgresql.conf, pg_hba.conf, and pg_ident.conf.
--- postgresql.conf ---
Within the main configuration file are four additional
parameters: include, hba_conf,ident_conf, and data_dir.
They are used as:
include = '/etc/postgres/debug.conf'
data_dir = '/vol01/postgres'
hba_conf = '/etc/postgres/pg_hba_conf'
ident_conf = '/etc/postgres/pg_ident.conf'
The -D option on the command line overrides the data_dir
in the configuration file.
If no hba_conf and/or ident_conf setting is specified, the default
$PGDATA/pg_hba.conf and/or $PGDATA/pg_ident.conf will be used.
This patch is intended to move the PostgreSQL configuration out of the
data directory so that it can be modified and backed up.
This patch is also useful for running multiple servers with the same
parameters:
postmaster -C /etc/postgres/postgresql.conf -D /VOL01/postgres -p 5432
postmaster -C /etc/postgres/postgresql.conf -D /VOL02/postgres -p 5433
To apply the patch, enter your PostreSQL source directory, and run:
cat pgec-PGVERSON.patch | patch -p 1
diff -u -r postgresql-7.3.2/src/backend/libpq/hba.c
postgresql-7.3.2.ec/src/backend/libpq/hba.c
--- postgresql-7.3.2/src/backend/libpq/hba.c Sat Dec 14 13:49:43 2002
+++ postgresql-7.3.2.ec/src/backend/libpq/hba.c Mon Feb 17 14:57:37 2003
@@ -35,6 +35,7 @@
#include miscadmin.h
#include nodes/pg_list.h
#include storage/fd.h
+#include utils/guc.h
#define IDENT_USERNAME_MAX 512
@@ -837,10 +838,22 @@
if (hba_lines)
free_lines(hba_lines);
- /* Put together the full pathname to the config file. */
- bufsize = (strlen(DataDir) + strlen(CONF_FILE) + 2) * sizeof(char);
- conf_file = (char *) palloc(bufsize);
- snprintf(conf_file, bufsize, %s/%s, DataDir, CONF_FILE);
+ /* Explicit HBA in config file */
+ if(explicit_hbafile strlen(explicit_hbafile))
+ {
+ bufsize = strlen(explicit_hbafile)+1;
+ conf_file = (char *) palloc(bufsize);
+ strcpy(conf_file, explicit_hbafile);
+ }
+ else
+ {
+ char *confloc = (explicit_isdir) ? explicit_pgconfig : DataDir;
+ /* put together the full pathname to the config file */
+ bufsize = (strlen(confloc) + strlen(CONF_FILE) + 2) * sizeof(char);
+ conf_file = (char *) palloc(bufsize);
+ snprintf(conf_file, bufsize, %s/%s, confloc, CONF_FILE);
+ }
+ /* printf(hba_conf: %s\n, conf_file); */
file = AllocateFile(conf_file, r);
if (file == NULL)
@@ -979,10 +992,22 @@
if (ident_lines)
free_lines(ident_lines);
- /* put together the full pathname to the map file */
- bufsize = (strlen(DataDir) + strlen(USERMAP_FILE) + 2) * sizeof(char);
- map_file = (char *) palloc(bufsize);
- snprintf(map_file, bufsize, %s/%s, DataDir, USERMAP_FILE);
+ /* Explicit IDENT in config file */
+ if(explicit_identfile strlen(explicit_identfile))
+ {
+ bufsize = strlen(explicit_identfile)+1;
+ map_file = (char *) palloc(bufsize);
+ strcpy(map_file, explicit_identfile);
+ }
+ else
+ {
+ /* put together the full pathname to the map file */
+ char *confloc = (explicit_isdir) ? explicit_pgconfig : DataDir;
+ bufsize = (strlen(confloc) + strlen(USERMAP_FILE) + 2) * sizeof(char);
+ map_file = (char *) palloc(bufsize);
+ snprintf(map_file, bufsize, %s/%s, confloc, USERMAP_FILE);
+ }
+ /* printf(ident_conf: %s\n, map_file); */
file = AllocateFile(map_file, r);
if (file == NULL)
diff -u -r postgresql-7.3.2/src/backend/postmaster/postmaster.c
postgresql-7.3.2.ec/src/backend/postmaster/postmaster.c
--- postgresql-7.3.2/src/backend/postmaster/postmaster.c Wed Jan 15 19:27:17
2003
+++ postgresql-7.3.2.ec/src/backend/postmaster/postmaster.c Mon Feb 17 12:14:12
2003
@@ -421,7 +421,7 @@
opterr = 1;
- while ((opt = getopt(argc, argv,
Re: [HACKERS] Roadmap for FE/BE protocol redesign
On 16 Mar 2003, Hannu Krosing wrote: Tom Lane kirjutas R, 14.03.2003 kell 19:15: Greg Stark [EMAIL PROTECTED] writes: So, just to throw out a wild idea: If you're talking about making large changes to the on-the-wire protocol. Have you considered using an existing database protocol? What I actually looked into was RDA, but I doubt that TDS would be any closer to our needs... I remember someone started cleaning up IO in order to move it into a separate module with the aim of making multiple implementations (RDA, TDS, XML, native JDBC wire protocol if it ever becomes a reality, etc.) possible. That was me, I did an initial cut of separating the FE/BE code from the rest, but ran short on time. Hoping to get back to it one of these days. My primary interest was in getting the DRDA protocol supported in a clean fashion. For those mentioning RDA, I believe that standard is pushing up the daisys. DRDA is about the only standards game in town at this point, it has client side support from just about every vendor (IBM obviously, Oracle, Sybase, MS) and server side support of some sort from DB2 and a couple others (MS SNA gateway, for example is/has a DRDA server). Mostly through gateways and add on products, but it's a far cry better than any other effort I'm aware of. While not exactly pertinent to new wire protocol this effort if completed would make it much easier to have backwards compatibility on the wire level. I think this would be a good idea all around, and would make future changes/replacements to FE/BE protocol a lot cleaner. Hannu Brian ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] cursors outside transactions
On Wednesday 19 March 2003 04:33 am, you wrote: Dave Cramer [EMAIL PROTECTED] writes: On Tue, 2003-03-18 at 19:00, Hiroshi Inoue wrote: ODBC(maybe JDBC also) has cross-transaction result sets (rather than cursors) since long by simply holding all results for a query at client side. JDBC is running into problems with this. Large queries cause out of memory exceptions. Cursors implemented as Neil suggests would cause out-of-disk exceptions. The limit is presumably further away than out-of-memory, but not any the less real. I'm concerned about this because, in my mind, one of the principal uses of cursors is to deal with too-huge-to-materialize result sets. Still, given that we have no prospect of a real solution any time soon, a limited solution might be a reasonable thing to offer for now. We have got more disk space than internal memory. Similar argument would be valid for swap in operating systems, but all operating systems have got swap and large results sets use swap, probably. 'Out of disk' is small problem - we can add more disk easy. Cursors out of a transaction are great features - the most important for clients in Java, but for other clients. regards Haris Peco ---(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: [HACKERS] string || NULL ambiguity
On Wed, 19 Mar 2003, Alvaro Herrera wrote: On Wed, Mar 19, 2003 at 10:26:05PM +0300, Oleg Bartunov wrote: we have a little problem in new version of tsearch we're currently working. We've implemented concatenation operation for txtidx type and treat concatenation with NULL as NULL (as it should be). But people get confused with such behaivour. Do we obliged to follow NULL rule ? It seems more natural in case of text searching to treat stringA||NULL as stringA. Why don't you just enclose the possibly NULL fields in COALESCE? stringA||COALESCE(NULL, '') we don't know in advance if it's NULL or not. Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(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: [HACKERS] MySQL at .NET conference
Anyway, on to MySQL. The had a booth there. I asked their technical guy a few questions and he seemed to have a decent understanding. When I asked the question, Why would I choose MySQL over something like PostgreSQL? his response was There is one company driving MySQL. Also, when we do a feature we think it through and deliver it completed. The PostgreSQL group tends to deliver things that aren't quite right or incomplete. I was taken aback by this. I don't think it is completely true, but I wonder what you guys think. I think it's substantially true :) Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [pgsql-advocacy] PostgreSQL flamage on Slashdot
On 19 Mar 2003 at 9:20, Josh Berkus wrote: Guys, You make an astute observation that I think should become a strategy of the advocacy team. That is to portray MySQL as a hobby database, but Postgres as a production database. I think this is a very easy stance to take, since I've always thought that. Anyone caught arguing that MySQL is better will show how much they don't know about Postgres or real databases. And why are we competing against MySQL, exactly? Look, the people who use MySQL aren't going to use PostgreSQL. They're looking for a fast, simple database with no DBA requirements, which IS NOT POSTGRESQL. Such databases have their niche just as we have ours. I have a growing feeling that the basis of perception that postgresql is slow stems from the arcane and age old defaults postgresql ships with. I know that they will be bumped in the next release but that does not help much to heal the mind share loss over the years.. Besides postgresql requires shared memory which is a system resource. I don't know much about mysql but my guess would be they can get as much resource runtime without intervention of root or kernel. That definitely plays to their advantage when people run out of box installations.. Our competitors are MS SQL, SQLAnywhere, Oracle, and DB2. Business-class databases. The tech press likes to focus on MySQL vs. PostgreSQL because they haven't caught up to the idea that an OSS database could compete with commmercial offerings. When *you* focus on MySQL vs. PostgreSQL, YOU ARE BUYING IN TO THEIR IGNORANCE, and helping the press compartmentalize Postgres as an alternative to MySQL. Agreed. Druming our features is the way to go. Not slamming other *OR* defending ourselves. Bye Shridhar -- byob, v:Believing Your Own Bull ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Faster NUMERIC implementation
I've been amusing myself the last several evenings by working on a reimplementation of the NUMERIC datatype, along the lines of previous discussion (use base-1 digits instead of base-10 so that the number of iterations of the inner loops decreases by a factor of about 4). It's not ready to commit yet, but I've got it passing the regression tests, and I find that it runs the 'numeric' test about a factor of five faster than CVS tip; so it seems worth doing. A couple questions for the group: 1. Has anyone got a problem with changing the on-disk representation of NUMERIC for 7.4? The only objection I can think of is that it'd prevent pg_upgrade from working ... but we don't have pg_upgrade capability right now anyway, and I've not heard that anyone is planning to make it happen for 7.4. 2. The numeric regression test probably isn't a good benchmark for this, since it spends most of its time pushing around numerics with hundreds of digits. I doubt that's representative of common usage. Can anyone offer a more real-world benchmark test? 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: [HACKERS] fixups for 7.3 to contrib directories
Patch applied. Thanks. --- Gregory Stark wrote: Just some fixups to a couple contrib directories I was trying out. . replace CREATE OR REPLACE AGGREGATE with a separate DROP and CREATE . add DROP for all CREATE OPERATORs . use IMMUTABLE and STRICT instead of WITH (isStrict) . add IMMUTABLE and STRICT to int_array_aggregate's accumulator function [ Attachment, skipping... ] [ Attachment, skipping... ] -- greg ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open 7.4 features
On Wed, Mar 19, 2003 at 05:45:39PM -0500, Bruce Momjian wrote: Here are a list of features that might be in 7.4. I know there are several people involved in each of these items. I think you forgot error codes and associated stuff. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Sallah, I said NO camels! That's FIVE camels; can't you count? (Indiana Jones) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] A bad behavior under autocommit off mode
Hiroshi Inoue wrote: Bruce Momjian wrote: OK, I have a patch to fix this bug. The basic problem is that when a multi-query string is passed to the backend, it is treated as a single transaction _unless_ a transaction or GUC command appears in the string. When they appear, a transaction is forced, but the normal transaction state machine has been bypassed, meaning in: SET autocommit TO off; SELECT 1; COMMIT; when the COMMIT arrives, the transaction state machines hasn't seen the SELECT because the mechanism is bypassing the state machine to try and get everything into the same transaction. This patch removes that stuff all queries into a single transaction behavior and makes them function just like queries arriving separately. This does BREAK BACKWARD COMPATIBILITY. However, if they want the old behavior, they just need to wrap BEGIN/COMMIT around the query string. Does the change worth the trouble ? Please don't break BACKWARD COMPATIBILITY easily. It clearly fixes an existing bug, and I asked on general to see if anyone has any problem with the change. My guess is that more people are surprised by the group-string-as-a-single-transaction as people who use the feature, so I see it as the removal of surprising functionality. We will mention it in the release notes, and I can even supply a patch for those who want it kept. In fact, I can easily make it a compile option --- the change is only a single conditional test. -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Nested transactions: low level stuff
Hiroshi Inoue [EMAIL PROTECTED] writes: Sorry I have a basic question. Was there any consensus we would introduce nested transactions (or savepoints) in the way currently discussed ? I think we are a long way from saying we can or will actually do it. Error handling and resource management (eg locks) are a couple of other huge cans of worms that have yet to be opened. But certainly a solid design for the transaction logging and tuple validity checking is a necessary step. My feeling is that the right way to proceed is to nail down a paper design for each of the major aspects of the problem, before anyone actually spends any time coding. There would be little point in implementing subtransaction logging if we don't know how to do the other things. regards, tom lane ---(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: [HACKERS] Open 7.4 features
Alvaro Herrera wrote: On Wed, Mar 19, 2003 at 05:45:39PM -0500, Bruce Momjian wrote: Here are a list of features that might be in 7.4. I know there are several people involved in each of these items. I think you forgot error codes and associated stuff. That is part of the wire protocol upgrade, I think. -- 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 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
