[GENERAL] Skip trigger?
Hi, I have a table with a row update trigger that is quite slow. The trigger finction basically sets some bits in a "changed" column depending on which values really changed. For some bulk updates it can be determined in advance that the trigger function will not have any effect. Is there any way to run an update query and specify that it should not activate the trigger. I know that I can disable the trigger and reenable it later; however other concurrent updates mights need it Best 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
[GENERAL] Optimizing query?
Hi,
I am trying to match items from 2 tables based on a common string.
One is a big table which has one column with entries like XY123, ABC44, etc
The table has an index on that column.
The second table is, typically, much smaller
select from tab1, tab2 where tab1.code = tab2.code;
This works fine and fast.
Now, as a variant, I have some entries like XY423A, XY423B, GF55A, GF55D in the
big table and want them to match XY423, GF55 in the second table
Variants I have tried
select from tab1, tab2 where tab1.code ~ (tab2.code||'($|[A-Z])');
select from tab1, tab2 where tab1.code ~ ('^'||tab2.code||'($|[A-Z])');
both take an enormous time. In the better case that I can subset (e.g. all
candidates in table 2
share initial "AX") I get back to manageable times by adding
and tab1.code ~ '^AX'
into the recipe. Actual runtime with about a million entries in tab1 and 800
entries in tab2
is about 40 seconds.
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
[GENERAL] Using a german affix file for compound words
Hi! We have a problem with importing a compound dictionary file for german. I downloaded the files here: http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/dicts/ispell/ispell-german-compound.tar.gz and converted them to utf-8 with iconv. The affix file seems ok when opened with an editor. When I try to create or alter a dictionary to use this affix file, I get the following error: alter TEXT SEARCH DICTIONARY german_ispell ( DictFile = german, AffFile = german, StopWords = german ); ERROR: syntax error CONTEXT: line 224 of configuration file "/usr/local/pgsql/share/tsearch_data/german.affix": " ABE > -ABE,äBIN " This is the first occurrence of an umlaut character in the file. I've found a view postings where the same file is used, e.g.: http://www.postgresql.org/message-id/flat/556c1411.4010...@tbz-pariv.de#556c1411.4010...@tbz-pariv.de This users has been able to import the file. Am I missing something obvious? ww -- 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] Using a german affix file for compound words
I'm using 9.4.5 as well and I used exactly the same iconv lines as you
postes below.
Are there any encoding options that have to be set right? The database
encoding is set to UTF8.
ww
Am 2016-01-28 um 17:34 schrieb Artur Zakirov:
On 28.01.2016 18:57, Oleg Bartunov wrote:
On Thu, Jan 28, 2016 at 6:04 PM, Wolfgang Winkler
mailto:wolfgang.wink...@digital-concepts.com>> wrote:
Hi!
We have a problem with importing a compound dictionary file for
german.
I downloaded the files here:
http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/dicts/ispell/ispell-german-compound.tar.gz
and converted them to utf-8 with iconv. The affix file seems ok when
opened with an editor.
When I try to create or alter a dictionary to use this affix file, I
get the following error:
alter TEXT SEARCH DICTIONARY german_ispell (
DictFile = german,
AffFile = german,
StopWords = german
);
ERROR: syntax error
CONTEXT: line 224 of configuration file
"/usr/local/pgsql/share/tsearch_data/german.affix": " ABE >
-ABE,äBIN
"
This is the first occurrence of an umlaut character in the file.
I've found a view postings where the same file is used, e.g.:
http://www.postgresql.org/message-id/flat/556c1411.4010...@tbz-pariv.de#556c1411.4010...@tbz-pariv.de
This users has been able to import the file. Am I missing something
obvious?
What version of PostgreSQL do you use?
I tested this dictionary on PostgreSQL 9.4.5. Downloaded from the link
files and executed commands:
iconv -f ISO-8859-1 -t UTF-8 german.aff -o german2.affix
iconv -f ISO-8859-1 -t UTF-8 german.dict -o german2.dict
I renamed them to german.affix and german.dict and moved to the
tsearch_data directory. Executed commands without errors:
-> create text search dictionary german_ispell (
Template = ispell,
DictFile = german,
AffFile = german,
Stopwords = german
);
DROP TEXT SEARCH DICTIONARY
-> select ts_lexize('german_ispell', 'test');
ts_lexize
---
{test}
(1 row)
--
*Wolfgang Winkler*
Geschäftsführung
wolfgang.wink...@digital-concepts.com
mobil +43.699.19971172
dc:*büro*
digital concepts Novak Winkler OG
Software & Design
Landstraße 68, 5. Stock, 4020 Linz
www.digital-concepts.com <http://www.digital-concepts.com>
tel +43.732.997117.72
tel +43.699.1997117.2
Firmenbuchnummer: 192003h
Firmenbuchgericht: Landesgericht Linz
Re: [GENERAL] Using a german affix file for compound words
Am 2016-01-29 um 10:21 schrieb Artur Zakirov:
On 28.01.2016 20:36, Wolfgang Winkler wrote:
I'm using 9.4.5 as well and I used exactly the same iconv lines as you
postes below.
Are there any encoding options that have to be set right? The database
encoding is set to UTF8.
ww
What output does the command show:
-> SHOW LC_CTYPE;
?
Did you try a dictionary from
http://extensions.openoffice.org/en/project/german-de-de-frami-dictionaries
?
You need extract from a downloaded archive de_DE_frami.aff and
de_DE_frami.dic files, rename them and convert them to UTF-8.
I now tried with a new install of postgres 9.4.5 from the debian
repositories and everything worked fine.
test=# select to_tsvector('german_ispell','warenkorb');
to_tsvector
-
'korb':1 'ware':1 'warenkorb':1
(1 Zeile)
The LC_CTYPE and LC_COLLATE are both set to de_AT.UTF-8. I guess setting
this values will fix the problem.
I'm goint to import the databases into the new instance and then I'll
try again.
Thanks for your help,
ww
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Composite types for composite primary/foreign keys?
Hello,
for some reason, I couldn't get an answer on the novice-list, so if
this is the wrong place to ask or if it's just in the manual, excuse me
and just drop me a hint to the place where I have to look for it...
As far as I understand from the (excellent, btw.) PostgreSQL
documentation, inheritance of primary or foreign keys is not (yet?)
supported. That's a pity, because it makes inheritance essentially
useless in my case: A database schema with 300-400 tables and a
strongly hierarchically structured identification schema using
composite primary keys. And also bulkloads of corresponding foreign
keys criss-crossing all over the schema.
But I am pathetically lazy >;->, so I ld like to save keystrokes and
thus I had the (maybe pathetic)idea to use composite types for the
composite primary (and foreign) keys. No luck again, it seems to me, as
according to the documentation: "since no constraints are associated
with a composite type, the constraints shown in the table definition do
not apply to values of the composite type outside the table".
I'm sorry, but I'm apparently too dump to actually figure out myself
whether this means that I can use a single composite type column as a
primary / foreign key or whether not...?
Obviously I can't define the constraint within the type definition ("no
constraints (such as NOT NULL) can presently be included"), but if I
define the (NOT NULL and PRIMARY/FOREIGN KEY) constraint on the single
(composite) key column in the table definition, will it work as I would
expect it from a composite primary/foreign key? If so, this would be
really great. Because it would make the whole schema much more readable
for a clueless moron like me. ;-) And it would also simplify mapping it
to a logical model in Python quite a bit.
TIA,
Sincerely,
Wolfgang Keller
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Composite types for composite primary/foreign keys?
Hello, and thanks for your reply. I'm sorry, but I'm apparently too dump to actually figure out myself whether this means that I can use a single composite type column as a primary / foreign key or whether not...? What have you actually tried? I wanted to simplify the schema and make it more "readable" for clueless morons like me. >;-> You can learn a lot by a few minutes of exploration at a psql prompt. Yes, I will have to get used to using the Postgres prompt just like I do with the Python prompt. ;-) Sincerely, Wolfgang Keller ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Linux v.s. Mac OS-X Performance
Hello, sorry for "butting in", but I'm just curious... resolution? http://archives.postgresql.org/pgsql-general/2007-11/msg00946.php conclusion? Mac was still pretty slow in comparison Anyway, how does MacOS X (both 10.4 and 10.5) compare to Windows (2000, XP, Vista etc.) on the same hardware? And Linux to (Free-/Net-/whatever) BSD? No flamebait, I'm just wondering whether the performance gain is worth the learning effort required for Linux or BSD compared to the Mac. Sincerely, Wolfgang Keller ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Linux v.s. Mac OS-X Performance
Hello, sorry for "butting in", but I'm just curious... resolution? http://archives.postgresql.org/pgsql-general/2007-11/msg00946.php conclusion? Mac was still pretty slow in comparison Anyway, how does MacOS X (both 10.4 and 10.5) compare to Windows (2000, XP, Vista etc.) on the same hardware? And Linux to (Free-/Net-/whatever) BSD? No flamebait, I'm just wondering whether the performance gain is worth the learning effort required for Linux or BSD compared to the Mac. Sincerely, Wolfgang Keller ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
Re: [GENERAL] Linux v.s. Mac OS-X Performance
Anyway, how does MacOS X (both 10.4 and 10.5) compare to Windows (2000, XP, Vista etc.) on the same hardware? And Linux to (Free-/Net-/whatever) BSD? Apple hardware gets so expensive for some types of database configurations that such a comparision doesn't even make a lot of sense. So far my experience with the effective price/performance ratio of Apple vs. other Hardware for my applications has been pretty good. E.g. it was impossible for me to find a similarly priced (Linux-/*BSD/Intel/AMD-)equivalent to my PowerMac G5 over here at the time when I bought it. Not to mention the required learning effort for Linux/*BSD compared to MacOS X, if I count it in (days x day rate)... For example, if you have an application that needs high database write throughput, to make that work well with PostgreSQL you must have a controller with a battery backed cache. Hmm, what would be the difference compared to plenty of RAM and a UPS (plus stand-by backup server)? Looks just like moving the "single point of failure" to adifferent hardware item, no...? If I have a PC, the entry-level solution in that category can be a random sub-$1000 system that runs Linux Can't find one over here for that price that does all the other things that need to be done in a typicle small office (fileserver, printserver, mailserver, calendar server,...) similarly well as my old G5 PowerMac. To turn this one into a part-time DB server, I'd just plug in an eSATA or SAS array (with PCIe adapter) and maybe another few GB of RAM (currently 4). Plus a backup tape drive. My world are environments with not more than at most 10 concurrent database clients at any given moment. But those won't want to wait, because they need to get actual work done. plus around $400 for a RAID card with BBC, and you've got multiple vendors to consider there (3Ware, Areca, LSI Logic, etc.) LSI drivers are not available for MacOS X on PowerMacs? Ouch. Also, in previous generations, the Mach kernel core of Mac OS had some serious performance issues for database use even in read-heavy workloads: http://www.anandtech.com/mac/showdoc.aspx?i=2520&p=5 "With the MySQL performance woes now clearly caused by OS X" Erm, systematic error here: It could also be that the MySQL implementation/configuration for the two different OSes was the source for the performance difference. I wouldn't use MySQL anyway, and I'm mostly interested in transaction performance (client waiting time until commit). I'm just wondering whether the performance gain is worth the learning effort required for Linux or BSD compared to the Mac. On both Windows (where you get limitations like not being able to set a large value for shared_buffers) My consistent experience with Windows over the last >15 years has been that it just won't multitask anymore as soon as one process does significant I/O. No matter what hardware you put underneath. and Mac OS X, PostgreSQL has enough performance issues that I feel using those plaforms can only be justified if platform compatibility is more important than performance to you. The point is that cost for "installation", "configuration" and "administration" must be taken into account. A dedicated individual just for that is simply out of question in this world where I live. So someone who's already available has to do all that in a (as tiny as possible) fraction of his/her worktime. With MacOS X it's feasible, but Linux/*BSD? I'm not so sure. Sincerely, Wolfgang Keller ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Composite types for composite primary/foreign keys?
adable (less fields) and to simplify the work in case the identification schema changes. Nonsense? Am I nuts? Is that in fact totally useless? Or is there a better (simpler) way to achieve this? TIA, Sincerely, Wolfgang Keller ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
Re: [GENERAL] settings for 8.2.5 on Mac OS X 10.4.11
The best thing is to fix the OS' ridiculously small shmem limits. I've got this in /etc/sysctl.conf: kern.sysv.shmmax=33554432 kern.sysv.shmmin=1 kern.sysv.shmmni=32 kern.sysv.shmseg=8 kern.sysv.shmall=8192 Dependency on the available RAM? and on a production DB you'd probably want shmmax and shmall a good bit higher. Don't forget to reboot after changing settings. Also, a "sysctl -a | grep shm" is a good idea to make sure it "took"; OS X is infamously picky about these settings. regards, tom lane A Macnerd as a core developer of Postgres? :-) Sincerely, Wolfgang Keller ---(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
[GENERAL] Internationalisation of database content (text columns)
(Since I got no replies on the novice list, I repost this question here) Hello, I'm working on a database schema which contains lots of "type code lookup" tables. The entries of these tables are also hierarchically related among themselves (subtype/supertype), to store rather large and quite complex taxonomies. Currently the schema does not provide for translation of the entries in these tables, although it is meant to be used for inter-company data exchange, i.e. for use by many different people having all different native languages. When searching for "best practice" guides about the topic of transparently translating database content, I came across about this example: http://rwec.co.uk/pg-atom/i18n.html The basic method looks pretty intuitive to me, except that I don't understand why it wouldn't be more obvious to use a composite type, with language codes as column names, instead of an array for the custom "translated text" data type. Any opinions from more experienced "mahouts"? Any obvious drawbacks of using such a composite type? Other than the fact that the schema has to be modified to add languages, which wouldn't be that desastrous in this case. Are there any other (better?) "best practice" methods for the internationalisation of database content? Maybe methods that use capabilities (e.g. text search/thesaurus?) already built-into PostgreSQL? BTW: Methods that use a single table to hold all translations for all strings in all tables of the entire schema are not very useful in this case, since it can't be excluded that depending on the context (i.e. the specific semantics of the specific "type code lookup" table) the translation of one and the same string in one language will be different in other languages. TIA, Sincerely, Wolfgang Keller -- 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] Windows Installation User account - Correct database for us
> H2 or SQLite can be very reasonable choices for in-app embedded > databases, so long as your app can operate within their constraints on > concurrency and data size. Firefox uses SQLite and the places.sqlite database is notorious for getting corrupted every five minutes. Libreoffice/Openoffice Base uses H2 and there are plenty of reports by users about data losses due to database corruption. Personally I'd *never* use an "embedded" database for anything. Sincerely, Wolfgang -- 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] Database Design: Maintain Audit Trail of Changes
>For several reasons (including operational and legal) once data are > entered in a table they cannot be changed or deleted without an audit > trail of the change, when it occurred, who made the change, and the > reason for it. Besides the need for storing additional information that the user who modifies the data may be required to enter manually, couldn't the function of simply tracking what was inserted, updated and deleted be implemented by an "eternal" transaction log that never gets purged, but regularly archived in partitions, PGP-signed (with a qualified key) if required to prove authenticity? After all, PostgreSQL maintains this automatically anyway, so why not use it? TIA, Sincerely, Wolfgang -- 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] Installing PostgreSQL on OSX Server
> I have installed and configured PostgreSQL on Windows, FreeBSD, and a > few Linux flavors, but never OSX. I have the basic directions > (http://www.enterprisedb.com/resources-community/pginst-guide) and > found a couple of articles / blogs, but really I'm not an Apple guy > so I don't want to miss anything or screw anything up. > > Is there anything I should watch out for? I have some wiggle room > (this is a development server at first), but I'd rather not break > anything. I would stay away from MacPorts. The last time I have been working with PostgreSQL on MacOS X, I used the installer from http://www.postgresqlformac.com/ There's also a different approach, that I've never tried: http://postgresapp.com/ Sincerely, Wolfgang -- 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] database design best pratice help
> In my db I have about one hundred tables like this: > > code > description > > To avoid to have a so great number of similar tables in the db > I wonder if it is a good idea to unify all these tables in one big > table like this: > > id > code > table_ name > description Bad idea. E.g. how do you want to warrant (integrity!) that records in the table point only to codes that are valid for this table. To implement this as a constraint and at object level would create an obfuscated mess. Besides, that "id" column is a bad idea as well. The primary key of such a table would have to be composed of "code" and "table_name", of course. > 2. only one controller to manage the table With any reasonable database framework that I know of, it's ridiculously trivial to declare these codes as de-normalises "one to many"-attributes at the object level. No need to implement *any* "controllers" at all. Sincerely, Wolfgang -- 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] Visual query builder for PosgreSQL?
> I'm looking for some good visual query builder which can be used by > non-tech people for some ETL tasks. Do you have any recommendation? Libreoffice Base? I know it has a visual query builder and it does support PostgreSQL, but I have no clue what it is worth, since I tend to use SQL instead. Sincerely, Wolfgang -- 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] Success stories of PostgreSQL implementations in different companies
> Even with that, some clients are being encouraged to change to > PostgreSQL to lower their companies costs in technologies, but very > often they ask if there are success stories of PostgreSQL > implementations in companies in our region or around the world, > success stories (if is possible) with some information like number of > concurrent users, some hardware specs or storage size. Not a company, but a pretty "big" installation, I guess: French Caisse Nationale des Allocations Familiales (welfare agency) is running on PostgreSQL: 123 local offices all over France 11 million families and 30 million people as "customers" 69 bio EUR annual turnover 168 databases, 4TB all databases together, largest database is 250 GB 1 bio SQL statements a day Sincerely, Wolfgang -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Generate LaTeX doc from PostgreSQL (autodoc)?
Hello, what would be the easiest way to generate documentation for a PostgreSQL database in LaTeX/LyX format? Autodoc doesn't seem to support LaTeX output directly... TIA, Sincerely, Wolfgang -- NO "Courtesy Copies" PLEASE! -- 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] Free Tool to design Postgres Databases
> I'am searching for a free tool to design a Postgre Database. There is > something similar to MySQL Workbench? http://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools I've tried out nearly every (affordable or free) ER tool that's available and so far the one I like the most is DB-Main (http://www.db-main.com/doc.php?id=to1&lang=2). Which is not mentioned on the page above. Sincerely, Wolfgang -- NO "Courtesy Copies" PLEASE! -- 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] multi-company design/structure ?
> Is it better to create multi databases or create multi schemas? You're missing one option imho: One database, one schema. > I am writing a program that can have multi instances. Sort like a finanical > accounting system that can have multiable companies. Where each company has a > different name but the tables are an exact match to each other. Then you could simply add a "company-id" column to every table (and make this column part of the primary key of each table). And if you run multiple instances of the program within _one_ company, then you can also add an "instance-id" column (and make this column also part of the primary key of each table). Sincerely, Wolfgang -- NO "Courtesy Copies" PLEASE! -- 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] Forms for entering data into postgresql
> I have developed an application using MS SQL. I have used MS Access > for creating forms to enter data into the database. I am thinking of > changing over to postgresql and would also like to use any other > available open source tool for creating forms. Are there any free > applications available for creating forms similar to the ones I have > made in MS Access?. Any alternative suggestions will be appreciated. Without Programming: LO/OO Base Kexi might get usable one day as well. Rekall is apparently dead, unfortunately. Using Python (far easier and more powerful than any dialect of "Basic"): With PyQt (& Sqlalchemy): Qtalchemy: www.qtalchemy.org Camelot: www.python-camelot.com Pypapi: www.pypapi.org With PyGTK: Sqlkit: sqlkit.argolinux.org (also uses Sqlalchemy) Kiwi: www.async.com.br/projects/kiwi With wxPython: Gui2Py: code.google.com/p/gui2py/ Dabo: www.dabodev.com Defis: sourceforge.net/projects/defis (Russian only) GNUe: www.gnuenterprise.org Sincerely, Wolfgang -- 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] Forms for entering data into postgresql
> Forms these days are written in HTML. Only by clueless/careless morons. HTML has never been, is not and will never be a usable GUI framework. And "web apps" are unusable garbage. Sincerely, Wolfgang -- 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] Forms for entering data into postgresql
> My interpretation of "Forms these days are written in HTML" means > most interfaces are web front ends to the cloud. Not a GUI framework. "Cloud", "web apps", yet more fashionable trendslang buzzwords. I am talking about worktools that actually help productive "information workers" to get useful work done with at least some efficiency. Sincerely, Wolfgang -- 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] Forms for entering data into postgresql
> >> Forms these days are written in HTML. > > > > Only by clueless/careless morons. > > > > HTML has never been, is not and will never be a usable GUI > > framework. > > > > And "web apps" are unusable garbage. > > Look -- I appreciate people with strong unorthodox beliefs but your > statement above is just reflecting a blatant disregard for reality. I don't disregard reality at all. I just try to at least make an effort to not confuse blind herd instinct with cognitive intelligence, not to mention technical competence. > Just about all software people use for everyday tasks anymore is > targeted for the web, including the email client I'm typing this in. "Web mailers" are a particularly illustrative example why "web apps" are ridiculous garbage. Just like "web forums" or "Google Apps". If I had to use those, I would cease to use computers at all. And I have started to use email and usenet with PINE on a Unix text console. > The vast majority of enterprise SaaS apps are web deployed and so so > are intranet applications. And they are totally unusable crap. > It's just the way things are and if you know your technologies you > can settle on a stack that approaches the RAD platforms of old in > terms of programming efficiency. Certainly not. Not to mention the issue of end-user productivity. Not to mention the deployment mess, both server- *and* client-side, with "web apps". Etc. and so on... Sincerely, Wolfgang -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
postgresql.org inconsistent (Re: [GENERAL] PG replication across DataCenters)
> http://www.postgresql.org/docs/9.3/static/different-replication-solutions.html? > Synchronous Multimaster Replication *snip* > PostgreSQL does not offer this type of replication (...) Now I compare that statement with: http://wiki.postgresql.org/wiki/Postgres-XC > Project Overview *snip* > Features of PG-XC include: *snip* > 2. Synchronous multi-master configuration Seems to me that the editing process of the different parts of postgresql.org somewhat lacks transactional semantics. >;-> Sincerely, Wolfgang -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: postgresql.org inconsistent (Re: [GENERAL] PG replication across DataCenters)
> > Seems to me that the editing process of the different parts of > > postgresql.org somewhat lacks transactional semantics. > > postgresql-xc is not postgresql, its a fork. As an end-user, why would I care. Since, besides that it's still open-source (even same license as PostgreSQL itself...?), it's following the PostgreSQL releases pretty closely. According to their roadmap, version 1.1 has been merged with PostgreSQL 9.2 and version 1.2 will be merged with 9.3. It would at least merit being mentioned in the doc, just like other "forks" or whatever you may call it, as long as they're open-source. Sincerely, Wolfgang -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: postgresql.org inconsistent (Re: [GENERAL] PG replication across DataCenters)
> >> postgresql-xc is not postgresql, its a fork. > > > It would at least merit being mentioned in the doc, just like other > > "forks" or whatever you may call it, as long as they're open-source. > > You seem to not realize how many forks of Postgres there are. I had mentioned just one. And that one does not only fill in a functionality gap that is pretty important when it comes to competition/advocacy vs. e.g. that database with the capital "O", but it is also mentioned already on postgresql.org. Honestly, don't try to tell me that the majority of the developers working on PostgreSQL are not aware of PostgreSQL-XC. > There's no way that we can even track them all, let alone cater > for them in our documentation. Just putting one single URL into the doc instead of the misleading statement that there's no such thing should have been less work than replying to me. >;-> Disclaimer: I have nothing to do with PostgreSQL-XC, I don't even use it myself, I just happen to know that it exists, even though I am just a "casual" user of PostgreSQL. Sincerely, Wolfgang -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: postgresql.org inconsistent (Re: [GENERAL] PG replication across DataCenters)
I should have cross-posted this to pgsql-docs from the beginning, sorry for the mistake. For pgsql-docs readers: The issue is that the official documentation misleadingly omits the existence of Postgresql-XC: http://www.postgresql.org/docs/9.3/static/different-replication-solutions.html? > Synchronous Multimaster Replication *snip* > PostgreSQL does not offer this type of replication (...) Whereas the wiki says in http://wiki.postgresql.org/wiki/Postgres-XC > Project Overview *snip* > Features of PG-XC include: *snip* > 2. Synchronous multi-master configuration Now back to the original thread: > Knowing the number of forks/projects based on Postgres, maintaining a > list on a wiki list the one below is just easier for everybody: > http://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling That one doesn't even list PostgreSQL-XC. For how man years has it been around now... Can't even remember any more. Instead it lists Postgres-R, which has been in koma for how long now... Can't even remember any more. BTW; No, I don't suffer from that brain disease that makes you lose your memory (can't remember the name of it any more... ;-). > Perhaps this list is not completely up-to-date, To call that an understatement would be an euphemism. It's simply misleading. And misleading potential users in search of solutions for their needs is *bad* for the PostgreSQL project. > but not adding that in the core documentation facilitates the work of > core maintainers. It gives you all the information you need as well. Guys, are you really not aware to *that* point how badly you shoot yourself (and the PostgreSQL project as a whole) in the foot with that single - wrong - phrase in the "official" documentation: "PostgreSQL does not offer this type of replication" Reading that phrase, the average O* DBA looking for a cheaper replacement will stop considering PostgreSQL and that's it. You're out of business. They won't look any further. Just stop arguing and put *one* *single* *phrase* in the official documentation instead like: "PostgreSQL itself does not provide this as a built-in functionality at the current stage, but there is an open-source "fork" freely available under the same license as PostgreSQL that does, for details read: http://wiki.postgresql.org/wiki/Postgres-XC"; Is that really too much work? Heck, give me write-authority on the documentation and I'll do it for you then. You've already wasted *way* more brain bandwidth and precious time arguing why that phrase is *not* there than it would take to put it there once for good. That's the kind of pointy-haired dysfunctionality I'd expect from a managed corporation, not from an open-source project. In fact I would guess that given how closely PostgreSQL-XC follows the releases of "pure" PostgreSQL and the fact that they use the same license, at some stage it may be merged entirely. Sincerely, Wolfgang -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [DOCS] Re: postgresql.org inconsistent (Re: [GENERAL] PG replication across DataCenters)
> > Instead it lists Postgres-R, which has been in koma for how long > > now... Can't even remember any more. > > Nope, it is actively developed and sponsored by Translattice. "Actively developed"? http://www.postgres-r.org/ lists the last entry in the column "News" on the right with a date of 2010-07-14. http://git.postgres-r.org/ lists the "Last Change" to Postgres-R as "2 years ago". http://www.postgres-r.org/downloads/ lists the last "Snapshot patch" with a date from 2010-08-29. The "Postgres-R Live-CD" has a date from 2006-07-04! Sincerely, Wolfgang -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [DOCS] Re: postgresql.org inconsistent (Re: [GENERAL] PG replication across DataCenters)
> It looks like it's been morphed into TED, the TransLattice Elastic > Database. From their FAQ[1]: > > TransLattice Elastic Database (TED) > > What’s the basis of TED? Did you write it from scratch? > > We started TED from PostgreSQL, a very robust, open-source, > ACID-compliant, fully transactional RDBMS and Postgres-R, a PostgreSQL > extension that provides efficient, fast and consistent database > replication . Extensive engineering enhancements allows TED to > maintain ACID semantic transactions while operating in a > geographically distributed cluster. > > [1] http://www.translattice.com/faq.shtml I could not find any valid technical information on that site that would give details about what version of PostgreSQL they are based on etc. And if they have anything more recent than postgres-r.org, their product doesn't appear to be open source, since I couldn't find anything to download there. In fact their entire site reads to me just like the usual salespromotionspeak nonsense written for pointy-haired morons. Excuse me, but I can't take those people really serious. If Bettina Kemme is working with them, she should at least make sure to get them a reasonably useful WWW site. Sincerely, Wolfgang -- 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] Multi Master Replication
> 2. With sync replication, you have coordination problems and > therefore it is never (at least IME) a win compared to master-slave > replication since all writes must occur in the same order in the set, > or you need global sequences, or such. *snip* > You will never get better read or write throughput, Better read throughput is trivial to achieve even with other solutions than multi-master replication. And for better write throughput, the developers of Postgres-XC (supported by NTT, among others) beg to differ: http://postgresxc.wikia.com/wiki/Postgres-XC_Wiki http://postgres-xc.sourceforge.net/ As does Bettina Kemme (of Postgres-R fame). Sincerely, Wolfgang -- 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] client that supports editing views
> Q1 => Can anybody recommend a >> desktop GUI tool (preferrably open > source) << for PG with customizable forms like Access or FileMaker? Without programming: - LO/OO Base: www.libreoffice.org, www.openoffice.org - Kexi: www.kexi-project.org - Rekall is apparently dead, unfortunately. Using Python: With PyQt: - Qtalchemy: www.qtalchemy.org - Camelot: www.python-camelot.com - Pypapi: pypi.python.org/pypi/PyPaPi/0.8 - Thyme: clocksoft.co.uk/downloads/ With PyGTK: - Sqlkit: sqlkit.argolinux.org - Kiwi: www.async.com.br/projects/kiwi - Glom: www.glom.org - Gemello: abu.sourceforge.net With wxPython: - Gui2Py: code.google.com/p/gui2py/ - Dabo: www.dabodev.com - Defis: sourceforge.net/projects/defis (Russian only) - GNUe: www.gnuenterprise.org Sincerely, Wolfgang -- 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] client that supports editing views
> This is now my ranked shortlist which I will evaluate further: > 1. Camelot: http://www.python-camelot.com - PyQt > 2. Dabo: http://www.dabodev.com - wxPython > 3. Gui2Py: http://code.google.com/p/gui2py/ - wxPython > 4. Kiwi: http://www.async.com.br/projects/kiwi - PyGTK > 5. Sqlkit: http://sqlkit.argolinux.org - PyGTK > > All other projects seem to be abandoned or don't support Windows > (besides Linux and Mac). > It's obviously a question of PyQt vs. wxPython (or PyGTK). > And it's also a question of tool support meaning if its WYSIWIG (like > Access/FileMaker/Foxpro), script-based (e.g. XForms) or pure > programming based. If I had the skills, I'd pick up Pypapi. It is in production use with several italian municipalities, but the developer has switched to Java for whatever reason. Sincerely, Wolfgang -- 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] ERD Tool
> Is there any open source ERD Tool for Postgresql Database. > I find some paid tools but looking for free tools. Free or open source? >;-> http://pgdesigner.sourceforge.net/en/index.html http://www.db-main.eu/ http://sourceforge.net/projects/dbdesigner-fork/ And a list of a lot of others: http://www.databaseanswers.org/modelling_tools.htm Sincerely, Wolfgang -- Führungskräfte leisten keine Arbeit(D'Alembert) -- 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 CRUD for joined tables
> I'm looking for FOSS PostgreSQL CRUD software, preferably > Perl-compatible, which will enable me to design input forms which can > handle input to tables which reference other tables by foreign key. > Most CRUD applications I have seen so far only deal with direct, form > field to table field input but I want to build forms which have the > same fields as a VIEW derived from multiple table joins. In other > words, I want the CRUD to handle the the joins. > > Any suggestions? Not for Perl, but Python: SQLalchemy. An ORM that allows you to have (nearly) arbitrarily complex mappings between your object model and the database tables. GUI frameworks that use SQlalchemy are: Sqlkit, Pypapi, Camelot, Qtalchemy. Sincerely, Wolfgang -- 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] Visualize database schema
> Can anyone advice about a tool to visualize a database schema? SQLalchemy, a Python module, can produce dot (Graphviz) output which you can load into your favourite diagramming application such as e.g. Omnigraffle, yEd or Dia: http://www.sqlalchemy.org/trac/wiki/UsageRecipes/SchemaDisplay Since this can be automated, it's nice for documentation work. For inclusion in LaTeX documents, the dot output can then be converted to TikZ with dot2tex, which is also implemented in Python: http://www.fauskes.net/code/dot2tex/documentation/ If you're looking for DB modeling tools, here's a pretty comprehensive list: http://www.databaseanswers.org/modelling_tools.htm Sincerely, Wolfgang Keller -- 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] Visualize database schema
> >> Can anyone advice about a tool to visualize a database schema? > > > > SQLalchemy, a Python module, can produce dot (Graphviz) output > > which you can load into your favourite diagramming application such > > as e.g. Omnigraffle, yEd or Dia: > > > > http://www.sqlalchemy.org/trac/wiki/UsageRecipes/SchemaDisplay > > You just made my day -- great stuff. ERD generation should be > automatic -- whenever I lay them out I feel like I'm fingerpainting. Unlike postgresql_autodoc, which cannot be "embedded" with Pgadmin, since it is implemented in Perl, which has an embedding-hostile License as someone once told me, this tiny script could easily be embedded with Pgadmin, since Python's license is deliberately embedding-friendly. And with dot2tex, it would be even possible to generate a complete, printable, well-typographed PDF documentation of any PostgreSQL database from within Pgadmin, through LaTeX. Sincerely, Wolfgang -- 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] Visualize database schema
> I could not get the script sqlalchemy_schemadisplay3.py to work with > sqlalchemy 0.7.8-1 (on Debian). Have you asked on the SQLalchemy mailing list? http://www.sqlalchemy.org/support.html#mailinglist Sincerely, Wolfgang -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Messy data models (Re: [GENERAL] Visualize database schema)
> Concerning auto-layout, most if not all tools I have used up to now > make a mess for anything that is not dead simple. If a data model can not be reasonably "untangled" by an auto-layout algorithm (such as e.g. Graphviz) for display as a human-readable graph, wouldn't that mean that this model is a mess from the modeling point of view? In fact, shouldn't reasonably well-designed data models at least mostly follow SER principles? In that case, they could be displayed essentially as a tree. Could the "messy-ness" (or not) of the display of a data model (given a standard alorithm such as Graphviz) be used as a criterion to judge whether the model is actually well-structured? Sincerely, Wolfgang -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: Messy data models (Re: [GENERAL] Visualize database schema)
> > In fact, shouldn't reasonably well-designed data models at least
> > mostly follow SER principles? In that case, they could be displayed
> > essentially
> as a
> > tree.
>
> No - and what the heck are "SER principles"?
Structured Entity Relationship model.
It means that the dependency graph does not contain directed cycles
("hen-and-egg"-type foreign key relations).
Sincerely,
Wolfgang
--
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] Some thoughts on table inheritance (which is uniquely awesome on PostgreSQL)
> 1) First, in LedgerSMB, What a pity that this is implemented in a write-only programming language and as a "web application" instead of an actual GUI... > we started using it to create consistent interfaces to sets of > storage tables. The storage tables would behave differently, but > would inherit essentially interfaces from their parents. In this > regard, you can think of an inheritance tree as a partitioned table > set, but where the partitioning is necessary because foreign key > fields reference different tables in different children. We use this > for example, to avoid having to have a global notes table or global > file attachments table and it gives us clear control over where these > can be attached along with central maintenance of data structures. > In cases, like with file attachments, where foreign keys to > inheritance trees ended up being needed, we started out with a more > complex but workable solution but I think are going to a simpler one. > This is a good thing. > > In essence what we did was use inheritance to give us variable target > tables for a foreign key column. I would still like to see > inheritable foreign key constraints because that would make some > things a lot easier, but the idea that foreign keys are not, by > default, copied in, means that you can override the destination in the > child table. It isn't the use documented but it actually works very > well. Is there some documentation (database schema, DDL, etc.) where this is described in detail? > 2) Secondly I re-read Stonebraker's "Object-Relational Database: The > Next Wave" and I had a rather sudden epiphany. Relational databases > are about modelling your data so you can ensure consistency and gain > as many answers as you can. Object-relational modelling adds > interfaces (possibly written in arbitrary programming languages) to > derive additional information from stored information. As a non-computer scientist by training, I thought object orientation from the purely utilitarian point of view would be essentially about inheriting common features such as attributes, methods etc. from base classes, respectively base tables in the case of an object-relational database, to reduce implementation effort for code, increase consistency etc... And about "encapsulating" methods (procedures) together with the classes (tables) that they work on. > 3) I was talking with Matt Trout regarding object-oriented > programming in Perl, and he turned me on to Moose::Role as essentially > an interface class. It cannot be instantiated and one would not > simply inherit it in order to instantiate it. Rather it provides an > ability to assemble classes from re-usable pieces and thus provide > consistent interfaces across a project.This has become a key to my > understanding of the use cases for multiple inheritance in PostgreSQL, > namely that you can define interfaces across column combinations and > combine those column combinations into a table. What's the difference from the use of custom composite types to aggregate tables? Except for access syntax? Sincerely, Wolfgang -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] SQL DATALINK (Re: Storing large files in multiple schemas: BLOB or BYTEA)
> > I need to store large files (from several MB to 1GB) in Postgres > > database. The database has multiple schemas. It looks like Postgres > > has 2 options to store large objects: LOB and BYTEA. However we seem > > to hit problems with each of these options. > > I believe the general consensus around here is to not do that, if you > can avoid it. File systems are much better equipped to handle files > of that magnitude, especially when it comes to retrieving them, > scanning through their contents, or really, any access pattern aside > from simple storage. > > You're better off storing the blob on disk somewhere and storing a > row that refers to its location. Either key pieces for a naming > scheme or the full path. What's the state of implementation (planning) for this?: http://wiki.postgresql.org/wiki/DATALINK Sincerely, Wolfgang -- 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] Tool to create database diagrams in postgreSQL
> Can anyone tell me which free GUI based tools are available for > creating database diagrams for my database in postgresql. One standard answer to this frequently asked question is: http://www.databaseanswers.org/modelling_tools.htm Sincerely, Wolfgang -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] postgresql_autodoc in Python?
Hello, has anyone ever implemented something similar to postgresql_autodoc in Python? TIA, Sincerely, Wolfgang -- NO "Courtesy Copies" PLEASE! -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] How to retrieve the comment for a constraint?
Hallo all, using at least PostgreSQL 7.4.2, one can use the command COMMENT ON CONSTRAINT ON ; to document a constraint defined via CONSTRAINT ... in the context of a table. Now, imagine you know the name of a constraint or all of them for a given table, e.g. destilled via SELECT * FROM information_schema.table_constraints WHERE table_name = ''; How can I get the comment for each of these constraints? I mean, I can query pg_catalog.pg_description with SELECT * FROM pg_description WHERE description ~ ' *'; and get the tuple objoid | classoid | objsubid | description with the string I want to extract. I can see that it is there. In short... Given names of schema, table and constraint, how can I get the description out of pg_catalog.pg_description? Do I overlook something in the forest of system catalogs, its OIDs, the information schema...? Thank you! Best regards, Wolfgang ---(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: [GENERAL] Adventures in Quest for GUI RAD
Hello, > But I know from past experience that I am not going to make a lot of > progress teaching myself any form of C language. I had to learn programming with Pascal at university first. It worked for me. Then I had to learn Fortran. Didn't like some things about it, but still managed to get it to work. Then I had to learn C and H-A-T-E-D it. Never used it and forgot everyhing about it after the class' final test. And then I heard about the existence of Python. The first language I learned voluntarily and the only one I'm still using. If Python didn't exist, I wouldn't have done anything related to programming since university. Just as I wouldn't use computers out of work if Macs didn't exist. > I should have made it clear that I am just a hobbyist teaching > myself in my spare time, for fun. I'm not a developer either. Nor am I using Python intensively in my job. Despite this I'm planning to spend a week (during my vacation!) at Europython this year. And the trip there plus the registration fee will cost me quite a bit of money - Sweden is expensive and not quite around the corner. What is nice about Python especially for non-professional programmers: - it scales from trivial throw-away command-line scripts (<=> Delphi) to beyond what you will ever need (the GNUe project is implementing an ERP system with it) - it interfaces with basically every kind of library, interface or whatever; you can use COM on Windows (<=> Java), Applescript on the Mac and lots of open source applications use it as their scripting language Consequently, Python alone is likely to get everything done that you will ever need in your whole life. And - Postgres suports it as a "second native" language for triggers, stored procedures etc. And - you don't have to deal with memory management (you can "help" the garbage collector by resolving cyclic references yourself, but you don't have to) > It is just too bad that there is not a better, more user friendly, > well documented front-end tool for Postgresql in open source. Err, you mean an IDE which allows to implement GUI applications (using Postgres or not) easily? For Python there are quite a few which use either wxPython or PyQt (or GTK, but those are for Linux and *BSD). One using wxyPthon is GNUe designer, although it is unfortunately badly (mostly un-)documented. Black Adder is an example for one using Qt. It even allows you to build not-open-source applications with PyQt due to a special licensing arrangement. OpenOffice forms allow to do nice things as well, with or without Python (via PyUNO). In fact imho instead of implementing yet another open-source database for 2.0, they should just have included a Postgresql (SDBC?) driver in OO. > I guess MSAccess is fine, except expensive. And it's REALLY limited in what you can do (not just concerning the amounts of data it can handle). > Also, given the fact that M$ has pulled the rug out from under > Visual Basic, one can never be too certain what the future will be > for something like MSAccess. Won't happen with Python. Even if Guido van Rossum would get run over by a truck tomorrow (which hopefully won't happen), it would keep getting developed, because it has grown far to usefull for far too many people. And no MS, Sun, Oracle or whoever can pull the plug on it. The same applies to wxWidgets. > Even the world of Visual Foxpro has in some ways slowly eroded > because of perennial rumors that Microsoft will withdraw support for > it. Some ex-Visual Foxpro developers are currently working on a replacement called Dabo and guess what they are using - Python and wxWidgets. > Perhaps the stunning success of the Open Source community is fueled > by the ruthless and fickle nature of companies such as Microsoft. > One would like to build upon some foundation that is not going to > disappear in a few years. Realbasic looks like an attractive > alternative to Visual Basic, but then that is one lone company which > is riding the Tusnami of the Windows operating system (although I > guess they are cross platform), Beep - RealBasic was implemented on the Mac first. :-) > but the point is, whatever one chooses to learn, if it is tied to > Windows, then its future is tied to the whims of Microsoft. Not necessarily. With Pyhon and wxWidgets or Qt, you can easily work on Windows, Linux, *BSD (and MacOS and Windows CE and PalmOS and your series 60 Nokia mobile phone and and and) today and not worry too much about whether (and on what system) you'll be able to use it tomorrow. Best regards Wolfgang Keller -- P.S.: My From-address is correct ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [GENERAL] Please Recommend a Front End App
Kurt Gibson wrote: > One important solution I created in Filemaker Pro requires very > detailed and exact replication of official court forms with database > data entered on the forms. Imagine a form with small type, boxes and > spacing that must be exactly as on the official form and data from > the database on the form as printed to pdf. One nice thing about > Filemaker is that its reporting ability is very flexible. There's a Python package which allows to create PDFs directly from Postgres: Openreport. It's made by the same company which has also implemented TinyERP (see below). Otherwise, OpenOffice has a nice database interface which allows to fill OO forms from Postgres, among others. > I also have an extensive solution with approx 50 tables/databases to > run my small business. TinyERP? It uses Postgres. > I am trying to migrate to linux and postgresql. I love the MacOS but > they just upgraded to 10.4 (tiger) and made 3 of my iMacs obsolete > because they do not have on-board firewire so are not supported by > 10.4. Ouch. X-( > Funny how Linux can be compiled to run on a 386 intel chip > from a floppy drive but MacOS cannot now run without firewire on a 4 > year old computer. Well, Jobs doesn't want to allow it to do so, because Apple needs to pay the fuel bills for his bizjet, I guess... Sincerely, Wolfgang Keller ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Adventures in Quest for GUI RAD
Alex Turner wrote:
> No.1 Python does not scale well.
> map x=new map();
Whatever that may mean. Reminds me why I deliberately forgot all of C
right after the final test of that class at university.
> vs
> self.d={};
Beep.
Go back to my initial article and read what I wrote. And try to
understand the word "to scale" in its context _there_.
> Python is 10x slower than C++ or Java.
Thanks for this "extremely differentiated" statement, as it makes clear
there is no point to discuss subjects like this with you any further.
Then for example the Ironport mailservers must really be aFata morgana,
or are there many mailservers out there that can handle 1 Mio messages
per hour on a moderately equipped desktop computer im plemented in
"Java" or C++...?
> If you do any kind of OO
> programming, python is very slow.
Well, if Python's too slow for you, then C or C++ are as well.
Because one can get compiled C speed simply by doing an "import pyrex",
adding some static declarations and feeding the Python code through
distutils - without having to touch C even with rubber gloves.
And don't get me into talking about "Java" applications - I've seen
quite a few of them, tried to use them for actual work and they all
failed miserably. There wasn't one among them which had a
"responsiveness" which actually deserved to be named as such and they
all leaked memory in such ridiculous amounts that after at most 30
minutes of usage the only way to get the computer out of its totally
frozen state was to physically pull the power plug. And this, no matter
how much physical RAM was installed.
> No. 2. Python does not inteface with everything by a long shot
> Case in point - no good native MS SQL Server Driver.
Well, if there's one in C or C++, there's also one in Python. And you
don't have to touch C(++) syntax even with rubber gloves to use it from
within Python.
The fact that no Python developer has met the requirement to wrap it in
a static DB-API-compliant module so far, just says a lot about the
usefulness of MS SQL Server for Python developers. Most of which are
people who tend to choose very carefully the tools they use.
And for those who don't mind paying a ridiculous amount of money for a
db server that does less than what Postgres does for free, there's
always mxodbc.
> No good PDF reading libraries.
Statement above applies. Plus any kind of COM component or scriptable
x application, as they're all usable from within Python.
Anyway, I seriously doubt that, as I know of at least one excellent
"native Python" DB->PDF _creation_ module.
> I love python alot, heck I wrote a whole web platform in it, but I'm
> under no illusions that it's much heavier that C++/Java or PHP.
None of those will be an option for the original poster, as he has
explicitly mentioned.
And none of those is able to "scale" across an application range as
wide as the one that Python does - by far.
> No offence of anything, but I've seen what non-professional
> programmers do in any language they get their hands on (Python, Java,
> Access/VBA), and for the most part, they should stick to their day
> job, and leave application development to people with good CS degrees
> who understand what they are doing (not that all CS graduates know
> what they are doing, they just have a better shot).
Sure.
According to you basically all of the applications that I know of as
being the "best of their breed" from personal experience through using
them on a daily basis to earn my living simply wouldn't exist - as they
have all been implemented by people who don't have a CS degree.
And I'm not talking about trendy webcrap, but things which are used
daily by _lots_ of people to get _actual work_ done.
Things like Framemaker, Catia, Simpack etc...
And, btw: http://learn.to/quote
End of flameware, subthread filtered.
Sincerely
Wolfgang Keller
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
[GENERAL] EMS PostgreSQL Manager vs. TheKompany DataArchitect
Hello, I'vesearchedforandtriednearlyeverydatabase administration/design tool available and it seems my choice has narrowed down to these two. Now a second opinion would be nice to have. Has anyone used one, better both of these? What do you think about them? TIA, Sincerely, Wolfgang Keller -- P.S.: My From-address is correct ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] EMS PostgreSQL Manager vs. TheKompany DataArchitect
Hello, > Both have trials - try it ;-) That's what I've done, as I mentioned. But sometimes others know/see things that I don't see/know, at least not within a restricted trial period. Sincerely, Wolfgang Keller -- P.S.: My From-address is correct ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Sun supporting PostgreSQL
Sun's support for PostgreSQL will involve: *snip* sponsorship of community members and projects; Given the focus of Sun on fault-tolerance etc., one of THE projects that they should definitely sponsor is http://gborg.postgresql.org/project/pgreplication/projdisplay.php Sincerely, Wolfgang Keller ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[GENERAL] "PoastgreSQL/SQLite Anywhere"?
Hello, for applications which require offline data collection/processing with PDAs and synchronisation/replication with a centralised server database (running on PostgreSQL), I was wondering whether it would be possible to set up an equivalent to *duck* Sybase SQL Anwhere using free software, maybe using SQLite for the mobile clients. Is there a solution which allows for automatic (but fully user-configurable) asynchronous replication between PostgreSQL and SQLite? TIA, Best regards, Wolfgang Keller ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[GENERAL] Checking of constraints via subqueries?
Hallo all,
in part VI (the reference), the online manual for 8.0.1 states for command
CREATE DOMAIN for parameter
CHECK (expression)
that currently
"...CHECK expressions cannot contain subqueries nor refer to
variables other than VALUE."
So, is this an item for the TODO list? I can't find it there. Or do I
overlook something?
This is also stated in the page about CREATE TABLE.
Best regards,
Wolfgang
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [GENERAL] Checking of constraints via subqueries?
Michael Fuhr wrote: On Thu, Feb 17, 2005 at 07:31:42PM +0100, Martijn van Oosterhout wrote: On Thu, Feb 17, 2005 at 11:03:58AM -0700, Michael Fuhr wrote: In experiments I've defined a domain's CHECK expression to call a function that makes queries. It worked in simple tests; I don't know if it'll work in the general case. The problem is basically that modifying a table elsewhere could have the effect of invalidating the entries in the table being checked. Yeah, that's the kind of thing that concerned me. I meant to ask the OP the usual question: What problem are you trying to solve? No problem actually. Realising a constraint via a CHECK () is a decision made by the developer. So the developer has to make sure that this fits in the whole picture and works the intended way. I'm thinking about the feature, and not about whether the use of this feature is dangerous or not. My starting point was the thought of using this for checking in CREATE DOMAIN. I see that the ubiquitous triggers could help (in an indirect way, being called with every INSERT or UPDATE of a row with that domain, but is this generic?). The other (subquery) option looks quite more elegant (and generic). And that may be the reason why it is mentioned in the docs: it seems to be an elegant and natural way the check a domain. Best regards, Wolfgang ---(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
