Re: [HACKERS] documentation udpates to pgupgrade.html
Colin, > To query for Postgresql services on Windows use: > > sc query type= service | find "postgresql" > sad news is that (at least on my computer) it only finds running services. Harald -- GHUM GmbH Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 Amtsgericht Stuttgart, HRB 734971 - persuadere. et programmare
Re: [HACKERS] documentation udpates to pgupgrade.html
Bruce, > > > NET STOP postgresql-8.4 > > NET STOP postgresql-9.0 > > > which should be extended by > > > > net stop postgresql-x64-9.0 > > > > for Windows 64 bit. > > > > Interesting. What I have added to HEAD and 9.0 docs is the attached > patch that explains the proper service name should be used. I don't > think I want to mention 64-bit explicitly, and in fact this section is > part of an 'e.g.' block, meaning they are just examples. yes, they are only examples ... just saying that with one additional example you could have all the fitting PostgreSQLs on Windows covered :) ... especially as learning about the correct service name is quite a nuisance (it gets named magically in a sensible fassion via the one click installer; it at least requires bringing up the service control panel and search for sth looking like PostgreSQL) Harald -- GHUM GmbH Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 Amtsgericht Stuttgart, HRB 734971 - persuadere. et programmare
[HACKERS] documentation udpates to pgupgrade.html
Hello, just doing an upgrade form PostgreSQL 8.4.4 on Windows 2007 64bit to PostgreSQL 9.0 64bit on the same system. I am working along http://developer.postgresql.org/pgdocs/postgres/pgupgrade.html There is written: NET STOP postgresql-8.4 NET STOP postgresql-9.0 or NET STOP pgsql-8.3 (PostgreSQL 8.3 and older used a different service name) which should be extended by net stop postgresql-x64-9.0 for Windows 64 bit. - It would also be helpfull, if there was a reamrk that pg_upgrade will try to write to the current directory - as "runas /user:postgres cmd.exe" usually starts within c:\windows\system; so a cd %TEMP% after runas would be valuable - -- GHUM GmbH Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 Amtsgericht Stuttgart, HRB 734971 - persuadere. et programmare -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch: Add JSON datatype to PostgreSQL (GSoC, WIP)
> I, for one, think it would be great if the JSON datatype were all in > core :-) However, if and how much JSON code should go into core >is up for > discussion. Thoughts, anyone? > in my opinion: As soon as possible. Spinning PostgreSQL as the Ajax-enabled-database has many great uses. Harald -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 no fx, no carrier pigeon - Using PostgreSQL is mostly about sleeping well at night. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Snapshot Materialized Views - GSoC
Pavel, b) create MV syntax? > - CREATE MATERIALIZED VIEW mvname AS ..., I think it is quite > obvious to do so, but I had to ask > please do not fortget the: create or replace MATERIALIZED VIEW option. And also the DROP if exists for the drop-command Best wishes Harald -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 no fx, no carrier pigeon - Using PostgreSQL is mostly about sleeping well at night.
Re: [HACKERS] Confusion over Python drivers
Greg, > The point isn't so much "standardizing". Having a low performance Python > driver turns into a PostgreSQL PR issue. I totally agree. >And if you're writing a database driver with performance as a goal, native Python is simply not >an option. yes. Additionally: performance is not the only challenge. A native Python implementation, without using libpq, will have to reimplement much of libpq - just let me isolate proper escaping, and will have its own bugs. Now, once *that* problem is under control, and there's a nicely licensed, > well documented, major feature complete, and good performing driver, at that > point it would be completely appropriate to ask "what about people who want > support for other Python platforms and don't care if it's slower?". Pure Pythondrivers do exist now; and they are allready discussed in the summaries - which is a good thing. With my remarks I just want to recommend that we at least should document a position for them; and a way ahead. And I need a place to point out that Python grew a FFI with ctypes. Maybe someone will think of a DBAPI2.0 compatible ctypes libpq wrapper ... Harald -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 no fx, no carrier pigeon - %s is too gigantic of an industry to bend to the whims of reality
Re: [HACKERS] Confusion over Python drivers
>The pg8000 / bpgsql seem to be toy projects, and anyway you dont >want to use pure-Python drivers in high-performance environments. I agree that there are some performance-challenges with pure-Python drivers. And we should not forget to look for the reasons for the incubation of that many pure-Python drivers: a) Python is no longer one-language, one-implementation. There are (at least) cPython (the original), Jython (on JVM), IronPython (from Microsoft on CLR), PyPy (Python on Python), Unladen Swallow (from Google on LLVM). In addition the nearly-Pythons as in Cython, RPython and ShedSkin Everything apart from cPython (and possible UnladenSwallow) has its challenges dealing with non-Python extension modules. From a developer standpoint it can be tempting to be able to rely on the same database adapter across more then one implementation b) the stabilization of an Python Application Binary Interface is in early discussion stage; meaning: it will take some time untill a non-Python extension can be usable across Python versions. c-Extensions are allways a major stumbling block on Python-n to Python-(n+1) versions c) Stability. Python code is same-on-same more robust then C-Code, as some of the crash-friendly-problems are eliminated (you cannot allocate memory wrongly within Python, you cannot errorly access memory cross array boundaries...) especially a) is a point to consider when standardizing on a PostgreSQL blessed Python-Postgresql-driver. How will the blessing extend to Jython / Ironpython / PyPy? Harald -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 no fx, no carrier pigeon - %s is too gigantic of an industry to bend to the whims of reality
Re: [HACKERS] Confusion over Python drivers
Marko, > I thought the topic was "Confusion over Python drivers"? > > The only bug there was likely app one, or at least its not widespread > so off-topic. Rest are more like non-essential cool features, > so again off-topic. > Those lack of "non-essential cool features" is right on topic - because what one developer may see as "non-essential" is the most important feature for the next developer. Exactly these kind of issues are the source of the confusion we now phase: developer B needing feature X, which was ignored by driver A. So I concur to put them on the discussion agenda; if they drop out of priority, at least it is documented WHY and will save other developers these thoughts. Harald -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 no fx, no carrier pigeon - %s is too gigantic of an industry to bend to the whims of reality
Re: [HACKERS] Confusion over Python drivers
Bruce,
http://wiki.postgresql.org/wiki/Python
>
> The first one listed, Psycopg, is noted as "preferred libpq-based
> driver", but the license is GPL. Isn't that a problem for many client
> applications?
>
> The licence of psycopg2 is a little more complicated; the "GPL" in that
summary just tries to sum it. The actual licence is: [from the LICENCE in
the source distribution]
-
psycopg and the GPL
===
psycopg is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version. See file COPYING for details.
As a special exception, specific permission is granted for the GPLed
code in this distribition to be linked to OpenSSL and PostgreSQL libpq
without invoking GPL clause 2(b).
Note that the GPL was chosen to avoid proprietary adapters based on
psycopg code. Using psycopg in a proprietary product (even bundling
psycopg with the proprietary product) is fine as long as:
1. psycopg is called from Python only using only the provided API
(i.e., no linking with C code and no C modules based on it); and
2. all the other points of the GPL are respected (you offer a copy
of psycopg's source code, and so on.)
Alternative licenses
If you prefer you can use the Zope Database Adapter ZPsycopgDA (i.e.,
every file inside the ZPsycopgDA directory) user the ZPL license as
published on the Zope web site, http://www.zope.org/Resources/ZPL.
Also, the following BSD-like license applies (at your option) to the
files following the pattern psycopg/adapter*.{h,c} and
psycopg/microprotocol*.{h,c}:
Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely, subject to the following restrictions:
1. The origin of this software must not be misrepresented; you must not
claim that you wrote the original software. If you use this
software in a product, an acknowledgment in the product documentation
would be appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not
be misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.
psycopg is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
Proprietary licenses
A non-exclusive license is available for companies that want to include
psycopg in their proprietary products without respecting the spirit of the
GPL. The price of the license is one day of development done by the author,
at the consulting fee he applies to his usual customers at the day of the
request.
-
Harald
--
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607
no fx, no carrier pigeon
-
%s is too gigantic of an industry to bend to the whims of reality
Re: [HACKERS] 8.5 vs. 9.0
> Wait for it > > 9.0. Yeah!!! -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 no fx, no carrier pigeon - %s is too gigantic of an industry to bend to the whims of reality -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] Windows x64 [repost]
Tatsuo, > Ok. Your suggestion is very helpfull. In general Tsutomu will wait for > feedbacks come in, probably until Jan 15th. > > BTW, is there anyone who wishes the patches get in 8.5? Apparently > Tstutomu, Magnus and I are counted in the group:-) But I'd like to > know how other people are interested in the patches. I am very interested. A 64bit-Windows-Version would give a boost perception-wise (I know the technical arguments about usefullness or not, but perception is different and often quite important) Harald -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 no fx, no carrier pigeon - %s is too gigantic of an industry to bend to the whims of reality -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Block-level CRC checks
>> I am in the process of adding a user-space "myhash" column to all my >> applications tables, filled by a trigger on insert / update. It really >> speeds up table comparison across databases; and it is very helpfull >> in debugging replications. > > Have you seen pg_comparator? yes, saw the lightning talk at pgday.eu it also uses md5 hashes, just in an own schema. Guess pg_comparator would profit from an integrated MD5 hash. Harald -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 no fx, no carrier pigeon - %s is too gigantic of an industry to bend to the whims of reality -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Block-level CRC checks
Kevin, > md5sum of each tuple? As an optional system column (a la oid)? I am mainly an application programmer working with PostgreSQL. And I want to point out an additional usefullness of an md5sum of each tuple: it makes comparing table-contents in replicated / related databases MUCH more feasible. I am in the process of adding a user-space "myhash" column to all my applications tables, filled by a trigger on insert / update. It really speeds up table comparison across databases; and it is very helpfull in debugging replications. Harald -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 no fx, no carrier pigeon - %s is too gigantic of an industry to bend to the whims of reality -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Application name patch - v2
> Sure. Here's a nice example from SQL Server as well as related doc links: > > http://blog.benhall.me.uk/2007/10/sql-connection-application-name.html > http://msdn.microsoft.com/en-us/library/ms189770.aspx > > http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring%28VS.85%29.aspx > that looks as if the entry defaults to the application name (argv[0]) > Similar features are available in Oracle: > > http://download.oracle.com/docs/cd/B10501_01/appdev.920/a96612/d_appin2.htm and I definitely know from Oracle, that the application name is the default without the progammer / user issuing any SET command. Would'nt this also make sense for PostgreSQL? That is, when no environment is set, and no SET-command is issued, that the application name becomes the default? Harald -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 no fx, no carrier pigeon - %s is too gigantic of an industry to bend to the whims of reality
Re: [HACKERS] Client application name
>I can have libpq look at the environment as it does for >PGCLIENTENCODING, but I'd certainly like to be able to use the >connection string as well, as environment variables are not really the another challenge with the Environment variable: they are (at least on windows) usually set for one logged on user. And ususally I have pg_admin, python for development, psql and my application all connected to the same PostgreSQL server. I would love to see 4 different application names, and not the value of one environment-variable. that argv[0] that was somewhere in this thread looked nice :) Harald -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 no fx, no carrier pigeon - %s is too gigantic of an industry to bend to the whims of reality
Re: [HACKERS] Feature Suggestion: PL/Js
> > I think Josh Tolley has some slides on how we built PL/LOLCODE that > could prove useful. > > BTW I've seen requests for PL/Js so I'm sure it'll be welcome. What > license is v8 under? > > the new BSD License http://code.google.com/p/v8/ -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 no fx, no carrier pigeon - %s is too gigantic of an industry to bend to the whims of reality
Re: [HACKERS] Alpha 1 release notes
within source code, build options there is: - Reserve the shared memory region during backend startup on Windows, so that memory allocated by starting third party DLLs doesn't end up conflicting with it. Hopefully this solves the long-time issue with "could not reattach to shared memory" errors on Win32. I suggest that it should also be pointed out that this fix will be backported to 8.3 and 8.4 (as much as I followed the ML); similiar to the information at - Fast shutdown stop should forcibly disconnect any active backends, even if a smart shutdown is already in progress. Backpatched to 8.3. best wishes Harald -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 no fx, no carrier pigeon - LASIK good, steroids bad?
Re: [HACKERS] generic options for explain
> The impression I have is that (to misquote Churchill) XML is the worst > option available, except for all the others. We need something that can > represent a fairly complex data structure, easily supports addition or > removal of particular fields in the structure (including fields not > foreseen in the original design), is not hard for programs to parse, > and is widely supported --- ie, "not hard" includes "you don't have to > write your own parser, in most languages". How many realistic > alternatives are there? > > One realistic alternative may be JSON: parsers for nearly all languages are freely available; everything web-affected speeks it perfectly; it's easier on the eye then XML, less bytes per information, addition and removal of fields as well as complex structures are possible. Harald -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 no fx, no carrier pigeon - LASIK good, steroids bad?
