Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Am Freitag, 19. Mai 2006 02:35 schrieb Robert Treat: > On Thursday 18 May 2006 12:38, Josh Berkus wrote: > > Personally, I'd go after MSSQL before I bothered with MySQL. Sure, > > let's make *migration* easier for those who wake up and smell the BS, but > > migration can (and probably should) be one-way. > > If you want to get users to swtich to your software from your competitors, > you have to eliminate barriers, and a big one for any database is getting > locked into a specific one. People aren't going to take the time to try > switching to postgresql if they can't easily make it back to thier former > database. It's one of the reasons why PostgreSQL's standards compliance is > so important; if you want to swtich to a new database, your best bet is to > give PostgreSQL a shot, because even if you don't like it, we're not going > to try and trap you into our software with bunches of non-standard knobs. > Low barrier to exit == low barrier to entry. The way to go are standards. If postgresql supports standard-sql (like we all know it know), mysql-users has to justify their apps to use standard-sql. What they gain is not only compatibility with PostgreSQL but compatiblity with all database-servers, which supports this standard. They wont have much trouble to switch back to mysql or downgrade their postgresql to oracle ;-), if they follow standards. Also if PostgreSQL would have a compatibility-layer, it has to follow every quirk of mysql and will be measured by that. Much better is to promote users of mysql to use standards. Tommi ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] BEGIN inside transaction should be an error
Am Mittwoch, 10. Mai 2006 22:23 schrieb Mark Dilger: > Martijn van Oosterhout wrote: > > On Wed, May 10, 2006 at 09:41:46AM +0200, Mario Weilguni wrote: > Could we make BEGIN fail when we already are in a transaction? ... > > Or if you really want to screw things up, you could require COMMIT; COMMIT; > to finish off the transaction started by BEGIN; BEGIN; We could just > silently keep the transaction alive after the first COMMIT; ;) > > ---(end of broadcast)--- > TIP 2: Don't 'kill -9' the postmaster I would expect after a COMMIT without an error, that my transaction is committed. When the system accidently issued a second BEGIN, this would not be the case. And what about BEGIN; BEGIN; ROLLBACK; COMMIT; then? Should the rollback be ignored also? I'd vote for breaking broken applications and leave the database-administrator reactivate this currently broken behavior of postgresql via GUC. Tommi ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Windows + IP6 progress
Hi, I don't have win32-headers here, but as far as I remember the headers (re-)#define many calls. getaddrinfo might be getaddrinfoA or something. When you don't use the headers and try to link with the name getaddrinfo, it is not found. The options are either look, what name is actually used for linking and test against this name (as an alternative of course) or include the needed header. Tommi Am Freitag, 19. August 2005 01:44 schrieb Andrew Dunstan: > The mingw header has pretty much this with WINSOCK_API_LINKAGE IN OUT > and FAR dissolved away. > > The standard test complains about it being an unresolved reference when > it is declared as "char getaddrinfo (); ". If we remove that and instead > include the header the test passes. I have no idea why that should be > the case for this function and not for others. > > cheers > > andrew > > Chuck McDevitt wrote: > >The definition in WS2tcpip.h > > > >WINSOCK_API_LINKAGE > >int > >WSAAPI > >getaddrinfo( > >IN const char FAR * nodename, > >IN const char FAR * servname, > >IN const struct addrinfo FAR * hints, > >OUT struct addrinfo FAR * FAR * res > >); > > > > > >(IN, FAR, and OUT are #defined to empty string). > > > >WINSOCK_API_LINKAGE is __declspec(dllimport) > >WSAAPI is __stdcall > > > >So, nothing magic with #defines of the name getaddrinfo. > > > >>-Original Message- > >>From: [EMAIL PROTECTED] [mailto:pgsql-hackers- > >>[EMAIL PROTECTED] On Behalf Of Tom Lane > >>Sent: Thursday, August 18, 2005 3:47 PM > >>To: Andrew Dunstan > >>Cc: PostgreSQL-development > >>Subject: Re: [HACKERS] Windows + IP6 progress > >> > >>Andrew Dunstan <[EMAIL PROTECTED]> writes: > >>>. what do we do about the getaddrinfo test? I'm almost inclined not > > > >to > > > >>>do it on windows, and assume that if we have ws2_32.dll we have it. > >> > >>There's something mighty fishy about that. AC_REPLACE_FUNCS works on > >>Windows for the other cases it's used for (no?), so what's different > >>about getaddrinfo? Perhaps Microsoft has #define'd that name as > >>something else, or some equally ugly crock? It'd be useful to look > > > >into > > > >>their header files and see exactly how and where getaddrinfo is > >>declared. > >> > >>regards, tom lane > >> > >>---(end of > > > >broadcast)--- > > > >>TIP 3: Have you checked our extensive FAQ? > >> > >> http://www.postgresql.org/docs/faq > > ---(end of broadcast)--- > TIP 2: Don't 'kill -9' the postmaster -- Mit freundlichen Grüßen Tommi Mäkitalo Dr. Eckhardt + Partner GmbH ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] IBM patent
Am Samstag, 29. Januar 2005 23:32 schrieb Marc G. Fournier: > On Wed, 26 Jan 2005, Christopher Browne wrote: > > Actually, the latter isn't so. > > > > If Mammoth or Pervasive or such release their own release of > > PostgreSQL, nothing has historically mandated that they make that > > release available under the BSD license. > > > > Presumably acceptance of the patent would change that. > > > > You and I might not have individual objections to this situation, but > > one or another of the companies putting together PostgreSQL releases > > very well might. > > But, there is nothing stop'ng them from replacing the ARC code with their > own variant though ... > And what if there are many more patented parts? If someone wants to have a patent-free variant, he has to replace big parts of postgresql? That wouldn't be good for postgresql. If there is a patent-problem, postgresql has to remove it. What I think about is the legal implications. Sorry, but I don't know BSD very well. Does BSD really allow to remove this BSD-license and put his own, or does BSD allow to release commercial closed-source-variants under the BSD-license? Tommi ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] IBM patent
Hi, I just read about this IBM-patent-issue at www.heise.de. IBM grants this patens to all projects, which follow one of the licenses, which are approved by the open-source-initiative. And the BSD-license is as far as I see approved (I found "New BSD license"). When releasing commercial closed-source-variants of postgresql this BSD-license stays intact, so the use of these patents in postgresql seems ok. Tommi Mäkitalo ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Question regarding dynamic_library_path
Hi, in linux you can change LD_LIBRARY_PATH in a running process, but it does not help. The library-loader initializes himself at process-startup and changing LD_LIBRARY_PATH do not change the actual path, the process is using for dlopen. Tommi Mäkitalo Am Dienstag, 8. Juni 2004 19:14 schrieb Thomas Hallgren: > From: "Bruce Momjian" <[EMAIL PROTECTED]> > > > I think the idea is that you want to specify the path in the config > > file, after the app has already started. I don't think you can modify > > the environment variable after the app has started, and even if you can, > > it seems simpler to just do it in our code and specify the exact path > > rather than having it poke around in whatever LD_LIBRARY_PATH is set to. > > Ok, that makes sense. But I think most systems have the ability to change > the environment of a running process (setenv on Posix systems) and the > current design, simple as it is, doesn't work in all cases. > > regards, > > Thomas Hallgren > > > > ---(end of broadcast)--- > TIP 7: don't forget to increase your free space map settings ---(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] email data type first release
... > > Another thing is that it might make more sense to sort email addresses by > domain first (case insensitively of course), then by left hand side (case > sensitively). Since the domain is really the "most significant bit". This > is also convenient for many systems like email since they perform better > when they can handle data in that order. > > Note that this would make the type sort differently from its text > representation. This shouldn't really be a problem but occasionally you see > poorly written queries that introduce extra type conversions that the user > doesn't expect. But then if it behaves just like the text datatype then > there wouldn't be much point in using it. Sorting should then be done by top-level-domain first. Then 2nd, 3rd... and last by user. [EMAIL PROTECTED] < [EMAIL PROTECTED] and [EMAIL PROTECTED] < [EMAIL PROTECTED] we get then the order: [EMAIL PROTECTED] < [EMAIL PROTECTED] < [EMAIL PROTECTED] < [EMAIL PROTECTED] rather than (in normal text-order): [EMAIL PROTECTED] < [EMAIL PROTECTED] < [EMAIL PROTECTED] < [EMAIL PROTECTED] Tommi ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] psql \d option list overloaded
Hi, > > 2) (using information schema ... little better) > > SELECT table_name FROM information_schema.tables WHERE table_schema > = 'public'; > > or ... > ... I just looked at the information_schema. It is a very nice feature, but difficult to use in psql. I just wanted to see, what I can find here. After trying and rtfm I ended in '\d information_schema.*'. I get a very large page wich is quite unreadable. '\d' is normally very usable. It would be better not to show the view-definition. What if \d on views just show the column, type and attribute. \d+ would show the full view-definition. Tommi -- Dr. Eckhardt + Partner GmbH http://www.epgmbh.de ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] psql \d option list overloaded
Am Sonntag, 4. Januar 2004 20:13 schrieb Alex J. Avriette: > On Sat, Jan 03, 2004 at 08:25:21PM -0500, Bruce Momjian wrote: > > > I finally figure it out, I just end up forgetting again later. I still ... > > /functions > /databases > ... Long options sounds really good. It is like GNU-tools. A single - for single character options and a double -- for long options. Ah - a single \ for short options in postgresql and a double \\ for long? What do you think? -- Dr. Eckhardt + Partner GmbH http://www.epgmbh.de ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Release cycle length
... > > Does anyone have a comparison of how many lines of code were added in > this release compared to previous? > 7.2.4: 456204 lines of code in 1021 files 7.3.4: 480491 lines of code in 1012 files 7.4: 554567 lines of code in 1128 files (boah!) I used a fresh extracted source-directory and executed 'find postgresql-7.xxx -name '*.c' - o -name '*.h'|wc -l' and 'find postgresql-7.xxx -name '*.c' - o -name '*.h'|xargs cat|wc -l' Tommi > Chris > > > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster -- Dr. Eckhardt + Partner GmbH http://www.epgmbh.de ---(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] Release now live ...
Hi, in doc/man1/psql.1 there is a line: "Welcome to psql 7.4beta5, the PostgreSQL interactive terminal." Tommi Am Montag, 17. November 2003 02:23 schrieb Marc G. Fournier: > 'k, I just moved the release into the /pub/source/v7.4 directory from the > v7.4beta one ... RC2 is still in place, so that I don't break a bunch of > links ... tomorrow night, I'll remove the RC2 ... > > > > ---(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 -- Dr. Eckhardt + Partner GmbH http://www.epgmbh.de ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] pg_ctl reports succes when start fails
Hi, I installed 7.4beta5, created a data-dir and tried to start postgresql with pg_ctl without initdb. As expected, this will fail. But pg_ctl tells me "postmaster successfully started", after a fatal error, which looks very confusing. When I use -l for specifying a logfile, I don't even see the error, but only the success-message. Tommi -- Dr. Eckhardt + Partner GmbH http://www.epgmbh.de ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Last beta ... we hope?
Hi, 7.4beta4 is still mentioned in INSTALL. Tommi Am Mittwoch, 22. Oktober 2003 16:21 schrieb Marc G. Fournier: > 'K, I packaged it up last night so that the ftp mirrors could get up to > date on it ... I'm going to put out an announce to -general and -announce > on this later this evening, but if someone wants to take a quick scan of > the tar ball to make sure that it all looks okay to them, that would be > great ... > > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > >http://archives.postgresql.org -- Dr. Eckhardt + Partner GmbH http://www.epgmbh.de ---(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] TCP/IP with 7.4 beta2 broken?
Hi, I just checked out the current CVS-version and everything is fine now on my SuSE 8.2-box. I set tcpip_socket in postgresql.conf to true and was able to connect to localhost and 127.0.0.1. I added my local IPv4-netaddress to pg_hba.conf and was able to connect to my networkadress. Thank you. Tommi Am Mittwoch, 10. September 2003 06:21 schrieb Bruce Momjian: > Are all the IPv6 issues resolved in current CVS? > > --- > > Tom Lane wrote: > > Andrew Dunstan <[EMAIL PROTECTED]> writes: > > > OK, now we are getting somewhere. I see that this would work. It's a > > > bit ugly, though - with this plan the sample file in both CVS and the > > > installation won't necessarily be what actually get put in place. > > > > Well, like I said, it's not real pretty. But the same is already true > > of postgresql.conf.sample --- initdb edits that. I don't see that > > having it edit pg_hba.conf.sample too is so bad. > > > > > What if some clever installer/administrator deliberately alters their > > > installed sample file? > > > > I don't think it would hurt them. The editing will consist of a sed > > script to comment or uncomment the line containg ::1, it wouldn't touch > > anything else. > > > > > Could we get the configure script to do it instead, since it too should > > > know about ip6 capability? (I guess then we'd have > > > pg_hba.conf.sample.in). That strikes me as being a lot cleaner. > > > > Bruce and I talked about that alternative too, but we felt that it made > > more sense to keep the processing of pg_hba.conf.sample parallel to what > > happens to postgresql.conf.sample. Further down the road we might need > > initdb-time checks to decide what to do to the sample file, just as we > > already need for postgresql.conf.sample. > > > > regards, tom lane > > > > ---(end of broadcast)--- > > TIP 4: Don't 'kill -9' the postmaster -- Dr. Eckhardt + Partner GmbH http://www.epgmbh.de ---(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] TCP/IP with 7.4 beta2 broken?
Hi, Am Mittwoch, 3. September 2003 20:16 schrieb Bruce Momjian: ... > > As for the IPv6 issue --- how prevalent is this problem. What OS > versions are affected? Has the user done something special to enable > this? I have a SuSE 8.2 out of the box. I have done nothing with IPv6. I don't even know much about IPv6. Users expect, that it works just after installation. But after following the discussion I think, that it is not so much a problem. I have 127.0.0.1 in my pg_hba.conf and when I set PGHOST to 127.0.0.1 it workes. If I set PGHOST to localhost, it resolves to ::1, wich don't match my pg_hba.conf-entry. The error message is somewhat clear and gives the user a good hint, where to look for. I don't like the idea of doing something special with loopback-interfaces. Loopback-interfaces are to test the network and tries to handle everything like normal networking. Is it possible to ignore IPv6-entries in pg_hba.conf on non-IPv6-machines? Then we could uncomment IPv6 localhost connections by default. Or uncomment these entries just on IPv6-machines. But this needs modification of default pg_hba.conf depending on OS. Tommi -- Dr. Eckhardt + Partner GmbH http://www.epgmbh.de ---(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] TCP/IP with 7.4 beta2 broken?
Am Dienstag, 2. September 2003 17:24 schrieb Andrew Dunstan: > *nod* but it would be nicer if all loopback interfaces worked by default > - hence my localhost suggestion, which would match any of > > 127.0.0.1/32 > > :::127.0.0.1/128 and > ::1/128 > > cheers > > andrew > ... That sounds good. Is it possible to extend lookup that way? And yes indeed - setting PGHOST to 127.0.0.1 workes but localhost not. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Hi, I doublechecked, that the patch applied. And there is a change. It workes for connections from remote or to the ethernet-address, but not to localhost: [EMAIL PROTECTED]:~ > export PGHOST=localhost [EMAIL PROTECTED]:~ > psql -l psql: FATAL: no pg_hba.conf entry for host "::1", user "postgres", database "template1" [EMAIL PROTECTED]:~ > export PGHOST=at31 [EMAIL PROTECTED]:~ > psql -l Liste der Datenbanken Name| Eigentümer | Kodierung ---++--- template0 | postgres | SQL_ASCII template1 | postgres | SQL_ASCII (2 Zeilen) [EMAIL PROTECTED]:~ > Tommi Mäkitalo ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Hi, the patch did not help. Maybe it would help dumping all pg_hba.conf-etries after generation of IPv6-adresses. But there is another problem, which is related. I get a logentry: LOG: could not bind IPv4 socket: Die Adresse wird bereits verwendet Sorry - I have errormessages in german - I set LANG to nothing, but it looks like not at the right place. It says, that the adress is already in use, but that is not true. Maybe postgres listens at the IPv6-socket first and therefore the IPv4-socket is also in use. Tommi Mäkitalo ... > > I created a patch to hba.c which uses IPV4 entries as IPV6 entries if > running on a IPV6 system (which is detected from a port coming in as > AF_INET6) > > Regards, > Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Am Dienstag, 2. September 2003 02:30 schrieb Andrew Dunstan: > Quick fix is probably to turn IPv6 off in the kernel unless it's needed > - on my RH box that is as simple as removing a line from > /etc/sysconfig/network and rebooting > Quick fix is to put the right IPv6-adresses into pg_hba.conf, like I did. The main problem is, that postgresql does not work out of the box. If it is possible postmaster should do some mapping from IPv4-entries in pg_hba.conf to IPv6-entries. > Kurt Roeckx knows more about this than I do, but I know when I turned > IPv6 on I had to do something similar to what is below - I seem to > recall we had a discussion about this somewhere. I think we (or at > least I) assumed that folks who turned on IPv6 would be able to figure > this stuff out for themselves. If distributions are starting to ship > with it turned on we may have to revisit that. > I did not switch IPv6 on. It was on after standard installation. Tommi Mäkitalo ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Yet another open-source benchmark
On the results page they list kernels like linux-2.4.18-1tier or
linux-2.4.19-rc2 or redhat-stock-2.4.7-10cmp. This sounds really like
linux-kernel-versions.
Am Montag, 3. März 2003 13:41 schrieb [EMAIL PROTECTED]:
> > OSDL has just come out with a set of open-source database benchmarks:
> > http://www.osdl.org/projects/performance/
> >
> > The bad news:
> > "This tool kit works with SAP DB open source database versions 7.3.0.23
> > or 7.3.0.25."
> >
> > (In fact, they seem to think they are testing kernel performance, not
> > database performance, which strikes me as rather bizarre. But anyway.)
>
> That may be a terminology thing; the main SAP-DB process is called the
> "kernel," and it's more than likely that the "SAP-DB Kernel" is the sense
> in which the term is being used.
>
> When they translate things from German, sometimes wordings change :-).
> --
> output = reverse("moc.enworbbc@" "enworbbc")
> http://www.ntlug.org/~cbbrowne/linuxxian.html
> Rules of the Evil Overlord #41. "Once my power is secure, I will
> destroy all those pesky time-travel devices."
>
[HACKERS] link to latest on ftp-site
Hi, the link to latest version points to the currently empty source/v7.3.1. Tommi -- Dr. Eckhardt + Partner GmbH http://www.epgmbh.de ---(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] [GENERAL] PostgreSQL Global Development Group
Am Donnerstag, 5. Dezember 2002 05:22 schrieb Lamar Owen: > [cc: list trimmed] > > On Wednesday 04 December 2002 22:52, Philip Warner wrote: > > At 05:48 PM 4/12/2002 -0800, Christopher Kings-Lynne wrote: > > >Lack of marketing is one of Postgres's major problems. > > > > What are the consequences of the problem? > > Actually, lack of easy upgrading is one of PostgreSQL's major problems > > But lack of focused marketing -- truthful, not, as has been said, like the > 'Database HOWTO' -- is a real problem. It would be nice to increase our > usage. > > > If that is what we want, then fine. But I don't want to see any part of > > the development effort distorted or the existing user base inconvenienced > > in an effort to purely gain that market share. I usually associate > > increased marketing with decreased quality, and I think the causality > > works *both* ways. > > ISTM there's a separate, non-code-developer group doing this. It doesn't > seem to take away _any_ developer resources to do an advocacy site. > > However, I seriously question the need in the long term for our sites to be > as fractured as they are. Good grief! We've got advocacy.postgresql.org, > techdocs.postgresql.org, odbc.postgresql.org, gborg.postgresql.org, > developer.postgresql.org, jdbc.postgresql.org, etc. Oh, and we also have > www.postgresql.org on the side? I think not. Oh, and they are fractured > in their styles -- really, guys, we need a unified style here. Hi, there are lots of sites talking about postgresql. But if someone hear about postgresql he sure tries www.postgresql.org. There he just get a list of mirrors. Not really a good start. But worse: there is no links to gborg, advocacy, techdocs, ... Advocacy should be found at www.postgresql.org and have links to the other pages. I found gborg when reading the mailinglistst. It is something like a insidertip. www.apache.org has a much better structure. You go to www.apache.org and get a welcome-message and links to subprojects as the webserver. Another point that comes to my mind is design. I'm not a designer, but I like the design of www.postgresql.org but not advocacy.postrgresql.org. Tommi -- Dr. Eckhardt + Partner GmbH http://www.epgmbh.de ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] MySQL update
Hi, I thought MySQL is marked as obsolete since PostgreSQL 7.3 ;-) Tommi Am Mittwoch, 4. Dezember 2002 03:55 schrieb Christopher Kings-Lynne: > Not that anyone cares, but I notice in the commit logs for MySQL 4.1, it > now has subselects. > > Chris > > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Dr. Eckhardt + Partner GmbH http://www.epgmbh.de ---(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] ALTER TABLE schema SCHEMA TO new_schema?
Am Sonntag, 1. Dezember 2002 06:47 schrieb Tom Lane: > Joe Conway <[EMAIL PROTECTED]> writes: > > Someone asked earlier about how to change a bunch of existing tables int > > the PUBLIC schema to some other schema. For grins I tried: > > regression=# update pg_class set relnamespace=556829 where relname = > > 'foo' and relnamespace=2200; > > UPDATE 1 > > > > and it seemed to work fine (i.e. moved foo from schema public to schema > > bar). > > But it didn't fix the pg_depend entries linking the table to its schema :-( > > > But it made me wonder if we shouldn't have: > >ALTER TABLE table SCHEMA TO new_schema > > I was thinking more along the lines of ALTER TABLE a.b RENAME TO x.y > > I don't see anything in the SQL spec about this; anyone know what > precedent is in Oracle or other DBMSes? > > regards, tom lane > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] Here is, what DB2 has to offer: DB2: Syntax DB2: DB2:.-TABLE-. DB2: >>-RENAME--+---+--table-name--TO--new-table-identifier->< DB2: DB2: Description DB2: DB2: |table-name DB2: Names the existing table that is to be renamed. The name, including the DB2: schema name, must identify a table that already exists in the database DB2: (SQLSTATE 42704). It can be an alias identifying the table. It must not DB2: be the name of a catalog table (SQLSTATE 42832), a summary table, a DB2: typed table (SQLSTATE 42997), a nickname, or an object of other than DB2: table or alias (SQLSTATE 42809). DB2: DB2: |new-table-identifier DB2: |Specifies the new name for the table without a schema name. The |schema DB2: name of the table-name is used to qualify the new name for the |table. DB2: The qualified name must not identify a table, view, |or alias that DB2: already exists in the database (SQLSTATE 42710). It looks like it is not possible to move a table from one schema to another. ALTER TABLE don't handle schemas either. But I like the "RENAME a.x to b.x"-syntax. Tommi -- Dr. Eckhardt + Partner GmbH http://www.epgmbh.de ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PERFORM] [HACKERS] Realtime VACUUM, was: performance of insert/delete/update
Or just reorg. Am Mittwoch, 27. November 2002 15:02 schrieb Nicolai Tufar: > I always wandered if VACUUM is the right name for the porcess. Now, when > PostgreSQL > is actively challenging in Enterprise space, it might be a good idea to > give it a more > enterprise-like name. Try to think how it is looking for an outside person > to see > us, database professionals hold lenghty discussions about the ways we > vacuum a database. Why should you need to vacuum a database? Is it > dirty? In my personal opinion, something like "space reclaiming daemon", > "free-list organizer", "tuple recyle job" or "segment coalesce process" > would > sound more business-like . > > Regards, > Nick > > > - Original Message - > From: "Bruce Momjian" <[EMAIL PROTECTED]> > To: "Curtis Faith" <[EMAIL PROTECTED]> > Cc: "Tom Lane" <[EMAIL PROTECTED]>; "Ron Johnson" <[EMAIL PROTECTED]>; > "PgSQL Performance ML" <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]> > Sent: Tuesday, November 26, 2002 9:09 PM > Subject: Re: [PERFORM] [HACKERS] Realtime VACUUM, was: performance of > insert/delete/update > > > Good ideas. I think the master solution is to hook the statistics > > daemon information into an automatic vacuum that could _know_ which > > tables need attention. > > > > - > >- > > - > > > Curtis Faith wrote: > > > tom lane wrote: > > > > Sure, it's just shuffling the housekeeping work from one place to > > > > another. The thing that I like about Postgres' approach is that we > > > > put the housekeeping in a background task (VACUUM) rather than in the > > > > critical path of foreground transaction commit. > > > > > > Thinking with my marketing hat on, MVCC would be a much bigger win if > > VACUUM > > > > was not required (or was done automagically). The need for periodic > > VACUUM > > > > just gives ammunition to the PostgreSQL opponents who can claim we are > > > deferring work but that it amounts to the same thing. > > > > > > A fully automatic background VACUUM will significantly reduce but will > > not > > > > eliminate this perceived weakness. > > > > > > However, it always seemed to me there should be some way to reuse the > > space > > > > more dynamically and quickly than a background VACUUM thereby reducing > > the > > > > percentage of tuples that are expired in heavy update cases. If only a > > very > > > > tiny number of tuples on the disk are expired this will reduce the > > aggregate > > > > performance/space penalty of MVCC into insignificance for the majority > > of > > > > uses. > > > > > > Couldn't we reuse tuple and index space as soon as there are no > > transactions > > > > that depend on the old tuple or index values. I have imagined that this > > was > > > > always part of the long-term master plan. > > > > > > Couldn't we keep a list of dead tuples in shared memory and look in the > > list > > > > first when deciding where to place new values for inserts or updates so > > we > > > > don't have to rely on VACUUM (even a background one)? If there are > > expired > > > > tuple slots in the list these would be used before allocating a new > > > slot > > from > > > > the tuple heap. > > > > > > The only issue is determining the lowest transaction ID for in-process > > > transactions which seems relatively easy to do (if it's not already > > > done somewhere). > > > > > > In the normal shutdown and startup case, a tuple VACUUM could be > > performed > > > > automatically. This would normally be very fast since there would not > > > be > > many > > > > tuples in the list. > > > > > > Index slots would be handled differently since these cannot be > > substituted > > > > one for another. However, these could be recovered as part of every > > index > > > > page update. Pages would be scanned before being written and any > > > expired slots that had transaction ID's lower than the lowest active > > > slot would > > be > > > > removed. This could be done for non-leaf pages as well and would result > > in > > > > only reorganizing a page that is already going to be written thereby > > > not adding much to the overall work. > > > > > > I don't think that internal pages that contain pointers to values in > > nodes > > > > further down the tree that are no longer in the leaf nodes because of > > this > > > > partial expired entry elimination will cause a problem since searches > > and > > > > scans will still work fine. > > > > > > Does VACUUM do something that could not be handled in this realtime > > manner? > > > > - Curtis > > > > > > > > > > > > ---(end of > > > broadcast)--- TIP 4: Don't 'kill -9' the > > > postmaster > > > > -- > > 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 > > 190
Re: [HACKERS] performance regression, 7.2.3 -> 7.3b5 w/ VIEW
Am Mittwoch, 13. November 2002 07:22 schrieb Ross J. Reedstrom: > Hey Hackers - ... > > CREATE VIEW current_modules AS >SELECT * FROM modules m > WHERE module_ident = > (SELECT max(module_ident) FROM modules > WHERE m.moduleid = moduleid GROUP BY moduleid); > ... I just wonder if you really need the GROUP BY. The subselect should return exactly one row and so max does without GROUP BY: CREATE VIEW current_modules AS SELECT * FROM modules m WHERE module_ident = (SELECT max(module_ident) FROM modules WHERE m.moduleid = moduleid); Tommi -- Dr. Eckhardt + Partner GmbH http://www.epgmbh.de ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] missing const in PQescapeBytea/PQunescapeBytea in 7.3b3
Hi,
I just discovered, that there is missing a const when passing a buffer to
PQescapeBytea and PQunescapeBytea. I fixed it and tried to create a usable
diff (I'm not so familar to diff).
Tommi
*** postgresql-7.3b3/src/interfaces/libpq/fe-exec.c 2002-09-04 22:31:47.0 +0200
--- postgresql-7.3b3tm1/src/interfaces/libpq/fe-exec.c 2002-11-02 22:28:34.0 +0100
***
*** 118,126
* anything >= 0x80 ---> \\ooo (where ooo is an octal expression)
*/
unsigned char *
! PQescapeBytea(unsigned char *bintext, size_t binlen, size_t *bytealen)
{
! unsigned char *vp;
unsigned char *rp;
unsigned char *result;
size_t i;
--- 118,126
* anything >= 0x80 ---> \\ooo (where ooo is an octal expression)
*/
unsigned char *
! PQescapeBytea(const unsigned char *bintext, size_t binlen, size_t *bytealen)
{
! const unsigned char *vp;
unsigned char *rp;
unsigned char *result;
size_t i;
***
*** 202,213
* 6 \\
*/
unsigned char *
! PQunescapeBytea(unsigned char *strtext, size_t *retbuflen)
{
size_t buflen;
unsigned char *buffer,
- *sp,
*bp;
unsigned int state = 0;
if (strtext == NULL)
--- 202,213
* 6 \\
*/
unsigned char *
! PQunescapeBytea(const unsigned char *strtext, size_t *retbuflen)
{
size_t buflen;
unsigned char *buffer,
*bp;
+ const unsigned char *sp;
unsigned int state = 0;
if (strtext == NULL)
*** postgresql-7.3b3/src/interfaces/libpq/libpq-fe.h 2002-09-04 22:31:47.0 +0200
--- postgresql-7.3b3tm1/src/interfaces/libpq/libpq-fe.h 2002-11-02 22:27:24.0 +0100
***
*** 249,257
/* Quoting strings before inclusion in queries. */
extern size_t PQescapeString(char *to, const char *from, size_t length);
! extern unsigned char *PQescapeBytea(unsigned char *bintext, size_t binlen,
size_t *bytealen);
! extern unsigned char *PQunescapeBytea(unsigned char *strtext,
size_t *retbuflen);
--- 249,257
/* Quoting strings before inclusion in queries. */
extern size_t PQescapeString(char *to, const char *from, size_t length);
! extern unsigned char *PQescapeBytea(const unsigned char *bintext, size_t binlen,
size_t *bytealen);
! extern unsigned char *PQunescapeBytea(const unsigned char *strtext,
size_t *retbuflen);
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] missing const it PQexscapeBytea/PQunescapeBytea in 7.3b3
Hi, my "other problems in PQescapeBytea" disappeared. I can't find them any more. I did some testing and all is fine. Tommi Am Sonntag, 3. November 2002 15:50 schrieb Bruce Momjian: > Tommi Mäkitalo wrote: > > Hi, > > > > not really. I can cast it away. Ugly, but it works. > > > > But I think it isn't that big, that it cant go into 7.3? It is really > > very local. It doesn't change anything. It should be very save. > > We are sort of in a code freeze so though it is little, I will keep it > for 7.4. Thanks. > > > I just write another C++-interface and c++ is more strict in checking. > > > > By the way: I think there are other problems in PQescapeBytea. It do not > > work as expected. It seems, than nobody is using it anyway. I am checking > > it right now. I will tell you about my researches soon. > > OK, let me know. -- Dr. Eckhardt + Partner GmbH http://www.epgmbh.de ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] tabcompletition and schema
Hi, I just installed 7.3b3 on my server (SuSE linux 8.1 on x86 with gcc 3.2) and discovered a problem with tabcompletition in pgsql. It doesn't work with schema. I created a schema 's' and a table 'tab' in this schema. When typing 'select * from s.' followed by tab nothing happens. A second tab should list me all possible values, but the list ist empty. Without schema it works fine. Tommi -- Dr. Eckhardt + Partner GmbH http://www.epgmbh.de ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
