Re: [HACKERS] Changing the concept of a DATABASE
Am 22.05.2012 15:27, schrieb Albe Laurenz: If you need different applications to routinely access each other's tables, why not assign them to different schemas in one database? I just saw another use case here. There are lots of offices / departments creating maps. Topography maps, pipeline maps, nature conservancy (e.g. where are the nests from endangered birds?), mineral resources, wire maps, street maps, bicycle / jogging maps, tourists maps, tree maps, cadastral land register, and so on. All this departments have their own databases for their own maps. They only map their own stuff. Towns / states / regions have a department where all these maps get collected. You can go to your town and ask for weird maps today - e.g. a map with all jogging routes and waste water pipes but without autobahns. You could say that you have one database per layer. As I said - I saw this construction in real world outside. I am pretty sure that other states maybe have other solutions but the described solution exist. Susanne -- Dipl. Inf. Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.com -- 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] Changing the concept of a DATABASE
Am 22.05.2012 15:27, schrieb Albe Laurenz: If you need different applications to routinely access each other's tables, why not assign them to different schemas in one database? The use case in my mind for accessing more databases is when you want to access stuff different languages. You only can set encoding / LC_Collate per database not per schema. So for different languages you might need different databases to do correct sorting / indexing. Susanne -- Dipl. Inf. Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.com -- 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] Changing the concept of a DATABASE
Am 22.05.2012 17:42, schrieb Tom Lane: Encoding yes, but since 9.1 we have pretty fine-grained control of collation. So I think this argument is a lot weaker than it used to be. It would only really apply if you have one of the corner cases where utf8 doesn't work for you. Yeah it got better - but it isn't perfect yet. Maybe I am blind or 9.1 documentation has a bug - but according to the documentation you can't change default collation per schema or per table. You can set collation per column - but do you really want to set collation for every single column of every single supported language in your 200+ tables web tool? That is a huge effort and a huge maintenance effort. Usually you want to set the collation once per language schema. E.g. schema russian gets Russian collation and schema British gets British collation and so on. CREATE SCHEMA foo LC_COLLATE bar isn't supported so you went up a level and do it by creating a database. I would like to get default collation per schema / table in 9.2 or 9.3 but that is my personal wish, Susanne -- Dipl. Inf. Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.com -- 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] Bug tracker tool we need
Am 18.04.2012 14:28, schrieb Robert Haas: So I think Greg has exactly the right idea: we shouldn't try to incorporate one of these systems that aims to manage workflow; we should just design something really simple that tracks what happened and lets people who wish to volunteer to do so help keep that tracking information up to date. I tested a lot tools for bug / issue tracking and I figured out that almost all of them either have had too much overhead or not really were made for database business. Additionally more often the sentence we support PostgreSQL just was a marketing trap. Means I figured out that the PostgreSQL support totally sucked. My opinion is that a tool should mirror your business and not that you build your business around the given tool. Looking for a bug tracking too - there are some points that are mandatory for us: 1. it should run on PostgreSQL 2. it should be open source - if possible BSD license - if possible there shouldn't be a single company behind it 3. it should be user friendly - no need to click here and there to get all informations 4. It should be able to communicate with our version control system - when we get the idea to move away from git to something else - it should be able by just a few changes that the tool will communicate with the new system 5. it should be possible to do almost all via email My personal dream would be that it would be possible to do almost all via irc bot but that is fiction. I think a tool should be slim and simple. It should exactly do what you want to do. You should be able to change the tool code that way that it exactly is doing what you want to do. Let me give you an example: bugs.mysql.com might be far away from being perfect. It is slim - and on developer side it has had all that the development needed. My information is that originally they took the code from the php bug tracking system and recoded it / implemented features so that it was doing a good job on database bugs. When the developers needed tool changes or additionally features then they just were coded. I never heard a developer saying that he hates the system. There just were lots of ideas how this or that could be solved better. That is normal - when you are working with the tool every day - of course you will get ideas what could be solved better. So yes - I think Greg is right. We should design something really simple that exactly is doing what we need. With some luck we might not need to start from scratch. Maybe there is a tool outside that is slim and good enough to deliver the base code on which we can start recoding. Just my 2ct, Susanne -- Dipl. Inf. Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.com -- 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] 9.3 feature proposal: vacuumdb -j #
Am 13.01.2012 22:50, schrieb Josh Berkus: Hackers, It occurs to me that I would find it quite personally useful if the vacuumdb utility was multiprocess capable. For example, just today I needed to manually analyze a database with over 500 tables, on a server with 24 cores. And I needed to know when the analyze was done, because it was part of a downtime. I had to resort to a python script. I'm picturing doing this in the simplest way possible: get the list of tables and indexes, divide them by the number of processes, and give each child process its own list. Any reason not to hack on this for 9.3? Hello, I like the idea - but ... I would prefer to have an option that the user is able to tell on how much cores it should be shared. Something like --share-cores=N. Default is total core number of the machine but users should be able to say - ok - my machine has 24 cores but I want that vacuumdb just will use 12 of them. Especially on startups - you are able to find machines that aren't database-only machines. Often you find database and web server as single machine. Also you could have run more cluster on same machine for offering your business in different languages (one cluster per language). I already saw such a setup. There might be side businesses on the cores - so it should be possible that the users decides on how much cores he wants to share vacuumdb. Susanne -- Dipl. Inf. Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.com -- 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] Removing postgres -f command line option
Heikki, On 17.11.2011 10:19, Heikki Linnakangas wrote: $ postgres --help ... Developer options: -f s|i|n|m|hforbid use of some plan types That doesn't include all the options we support, the documentation lists: s|i|o|b|t|n|m|h. These are aliases for enable_* planner options, e.g -fs is equal to enable_seqscan=off. That seems completely useless to me, because you can also do -c enable_seqscan=off. Any objections to removing the -f option altogether? I knew about it. But - I never needed it and I always scroll over it when I show --help in my trainings. When I was young - some when in last century - I learned that you never should remove a feature without pre-announcing it as deprecated. I think it is better to mark it deprecated in 9.2 and totally remove it in 9.3. Susanne -- Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.com -- 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] Is there really no interest in SQL Standard?
Hello Alvaro, On 16.09.2011 15:08, Alvaro Herrera wrote: It's certainly possible to create a private mailing list to support this idea. How would the membership be approved, however, is not clear to me. Would we let only well-known names from other pgsql lists into it? (I, for one, had no idea you were in the SQL committee.) It will be personally me - who gets the penalty when something get outside the group who is supporting me. Members should be people that I can trust. Besides core team I trust all who core team trust. And of course there are ppl outside core team who I am trusting. Susanne -- Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.com -- 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] Is there really no interest in SQL Standard?
On 19.09.2011 15:50, Josh Berkus wrote: +1 for a closed mailing list. It's a bit annoying to have to do such a thing, but it's not like we haven't got other closed lists for appropriate purposes. I guess the real question is, exactly what will be the requirements for joining? Well, one requirement would be agreeing not to share anything discussed in public without a vote of the entire group. Annoying, but that's how confidential drafts go. Exactly. Honestly, I don't expect that it will get a big group. It is very dry stuff. FWIW, the fact that the drafts *are* confidential is symptomatic of everything which is wrong with the ISO. +1 - But all suggestions to change it got rejected. Also, Suzanne indicated that summaries of what features were being discussed could be posted in public, even if details could not be. I looked into it - I fear it will get too gibberish. You sometimes just need the details. Also - just forwarding it - is much easier and less time intensive for me. Susanne -- Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Is there really no interest in SQL Standard?
Hello all, what I saw on PHP unconference told me that I should ask all again. I feel lonely. Believe me it is a bad feeling when it seems that nobody has interests in what you are doing. Since 4 years I am PostgreSQL representative in SQL Standard committee. Always, when I suggested to talk about my work in the SQL committee on community events, a committee rejected it. This just showed me that nobody really has interests in my work. I now learned that such a event committee not always is able to estimate interests correct. The only two persons who sometimes support me are David F. and Peter. The next ISO meeting will be soon - and of course there are lots of drafts that needs decisions. I am not allowed to share the drafts in public. Because the drafts are confidential. But I am allowed to share the drafts with the group of ppl who are supporting me. Of course I am allowed to discuss the drafts with my folk before I will give my votes and comments. Is there really only David and Peter who have interests? I not really want to believe it. Isn't it possible to create a closed mailing list - a list that won't get published - on which I can discuss SQL Standard stuff with the folk who wants to support me? I don't fear to make decisions on my own - but speaking for the whole project without getting feedback - is a worse feeling. Usually, when I feel unsure how I should decide I just bother Peter - but I would prefer to have some more ppl in my background. Susanne -- Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.com -- 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] Is there really no interest in SQL Standard?
Dave, On 16.09.2011 14:33, Dave Page wrote: On Fri, Sep 16, 2011 at 7:24 AM, Susanne Ebrecht susa...@2ndquadrant.com wrote: Since 4 years I am PostgreSQL representative in SQL Standard committee. With respect, I believe you are on the committee as you were an employee of MySQL. Nope. As Sun employee - I always was responsible for taking care of Postgresql - taking care of MySQL others did. An event committee is not approving talks because the work is important to the community - they are approving talks that will be of interest to the conference audience. You exactly hit the point here - where I had another opinion for what a community event also is. But doesn't matter. As I said - I just learned. Susanne -- Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.com -- 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] Is there really no interest in SQL Standard?
Heikki, On 16.09.2011 08:49, Heikki Linnakangas wrote: Even if you can't share drafts, would it be possible to give a summary of things that are being discussed in the committee? That way if there's people in the community with interests in particular topics, they could contact you and get involved. Of course it is. I just not wanted to spam hackers. FWIW, I'm very glad you're on the committee! Even though I have no idea what's going on there, it gives me a warm feeling that there's someone on the committee who knows PostgreSQL. If someone proposes something that would hurt PostgreSQL, like syntax that we already use for something else, I know you're going to speak up. Thanks for the bouquet. This comment let me feel better. Susanne -- Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.com -- 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] Is there really no interest in SQL Standard?
On 16.09.2011 14:47, Dave Page wrote: My point remains - Sun were never in a position to say who represents PostgreSQL. Dave, the procedure works different. The country representation ask for you. Because you represent your product on one side - but you also represent your country. For example ANSI offered Sun to send some experts. If BSI wants your expertise then they would ask you or your company (don't know how BSI works internally). Germany ask for my PostgreSQL expertise. Of course Peter always was and still is in my background. Finland just has no active group yet - afair Peter is working on that problem. Susanne -- Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.com -- 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] Is there really no interest in SQL Standard?
On 16.09.2011 14:38, Merlin Moncure wrote: So, generally speaking, what kinds of things are going to be brought up at the ISO meeting? Is this an opportunity to get postgres special syntax drafted into the sql standard? Yes and no. You first need to convince your country and then - as country representative - you need to convince the other countries on ISO level. You have country based sql standard groups in several countries. The well known groups are ANSI for USA, BSI for UK, DIN for Germany, JTC for Japan and so on. Inner the country you usually represent your own product. Usually the country based group members are a mix of research folk (e.g. universities) and DB-System companies placed inner the country. Which experts they will let in and which not depends on the country based group. It is good here to be in a smaller country - because the groups are smaller and you can get more of your ideas up to ISO. All the country based groups together are ISO. In ISO every country just has a single vote. This means - even when your country suggested what you wanted then it could happen that there are enough countries against it so that your idea won't get into the standard. Susanne -- Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.com -- 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] Is there really no interest in SQL Standard?
On 16.09.2011 15:59, Dave Page wrote: other plans less than 2 years ago. For me, a representative would have been reporting back to us after each meeting, and discussing points to raise before each meeting - not working in isolation, without the knowledge of others. Dave, I exactly did this with Peter. Afair, I once was told it is enough to report to Peter. And as I said - David showed interests and we sometimes talk about it too. I never wanted to bother hackers with all this stuff. Susanne -- Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.com -- 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] FDW table hints
On 03.05.2011 09:30, Magnus Hagander wrote: Well, yeah, but I don't think we can squeeze that into 9.1 without Robert noticing :P Any suggestions on *what* the hint should be? Just something along the line indexes cannot be created on foreign tables? Magnus, I am not really sure if this is clever. When we make such a hint for foreign tables then we should make a similar hint for views. Just my 2ct, Susanne -- Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.com -- 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] stored procedures
On 21.04.2011 17:24, Peter Eisentraut wrote: I would like to collect some specs on this feature. So does anyone have links to documentation of existing implementations, or their own spec writeup? A lot of people appear to have a very clear idea of this concept in their own head, so let's start collecting those. Peter, what I like from the other is that store procedures are able to return result sets. Susanne -- Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.com -- 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] [DOCS] found a very confusing and maybe outdated sentence
On 04.04.2011 01:51, Robert Haas wrote: On Sat, Apr 2, 2011 at 3:31 AM, Susanne Ebrechtsusa...@2ndquadrant.com wrote: Is man really working on Windows? Also the sentence says that the whole product isn't correct installed just because docs aren't installed. Which also isn't really true. Honesty, I just would like to drop the whole sentences. What do you think? +1 for deleting the entire sentence. Here is the patch for removing the whole sentence. Hmm... this actually removes two sentences. I've committed the removal of the one we talked about; I don't particularly see any reason to remove the following one also. Hello Robert, the second sentence says these features - and I would understand: these features == man pages Means, I would understand that the two sentences belong together and both talk about man pages. When we don't mention man pages anymore then we not need the sentence that tells that the tutorial won't take care about man pages. Susanne -- Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [DOCS] [HACKERS] Uppercase SGML entity declarations
On 04.04.2011 18:37, Tom Lane wrote: AFAIK, the main stumbling block for that is that XML doesn't allow abbreviated close tags (ie,foowhatever/). Which is something that we are not likely to give up. So I'm not sure of the point of changing something as trivial as entity declaration casing. You're going to end up having to fork the documentation anyway, or at least feed it through an SGML to XML converter. So why not fix the entity casing then? Tom, Honestly, for German I don't mind yet if it is XML or SGML. XML might be better in future for maintenance tools. Anyway, I figured out there is another argument for XML: My information is that DocBook 5.0 won't support SGML anymore. Which means - sooner or later a reaction is needed. Susanne P.S.: Btw. I change foowhatever/ into foowhatever/foo when it is in the parts which I am translating because my emacs indent don't like /. -- Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [DOCS] [HACKERS] Uppercase SGML entity declarations
On 04.04.2011 21:08, Tom Lane wrote: Indeed. One thing I'd like to know is whether docbook v5 is any more portable/easier to install Unfortunately, as far as I know - there isn't a huge difference. regards, Susanne -- Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] fixed doc bug in sepgsql.sgml
Hello, by accident we recognised that the author of sepgsql.sgml used and instead of lt; and gt; I just fixed it and here is the patch. Susanne -- Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.com diff --git a/doc/src/sgml/sepgsql.sgml b/doc/src/sgml/sepgsql.sgml index 21b46de..589fe79 100644 --- a/doc/src/sgml/sepgsql.sgml +++ b/doc/src/sgml/sepgsql.sgml @@ -105,7 +105,7 @@ $ initdb $ vi $PGDATA/postgresql.conf $ for DBNAME in template0 template1 postgres; do postgres --single -F -O -c exit_on_error=true $DBNAME \ - /usr/local/pgsql/share/contrib/sepgsql.sql /dev/null + lt; /usr/local/pgsql/share/contrib/sepgsql.sql gt; /dev/null done /screen -- 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] [DOCS] found a very confusing and maybe outdated sentence
On 31.03.2011 18:13, Robert Haas wrote: On Tue, Mar 29, 2011 at 3:07 PM, Susanne Ebrecht susa...@2ndquadrant.com wrote: Hello, It is in start.sgml. You can see it here: http://www.postgresql.org/docs/9.0/static/tutorial-accessdb.html The last two sentences on the page: If PostgreSQL is installed correctly you can also type man psql at the operating system shell prompt to see the documentation. In this tutorial we will not use these features explicitly, but you can use them yourself when it is helpful. Isn't that totally outdated? Is man really working on Windows? Also the sentence says that the whole product isn't correct installed just because docs aren't installed. Which also isn't really true. Honesty, I just would like to drop the whole sentences. What do you think? +1 for deleting the entire sentence. Here is the patch for removing the whole sentence. Susanne -- Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.com diff --git a/doc/src/sgml/start.sgml b/doc/src/sgml/start.sgml index 4275bf8..0bfc25e 100644 --- a/doc/src/sgml/start.sgml +++ b/doc/src/sgml/start.sgml @@ -403,11 +403,7 @@ mydb=# command shell. (For more internal commands, type literal\?/literal at the commandpsql/command prompt.) The full capabilities of commandpsql/command are documented in -xref linkend=app-psql. If productnamePostgreSQL/ is -installed correctly you can also type literalman psql/literal -at the operating system shell prompt to see the documentation. In -this tutorial we will not use these features explicitly, but you -can use them yourself when it is helpful. +xref linkend=app-psql. /para /sect1 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [DOCS] patch for createdb section in tutorial
Hello, During translating the docs I found the following sentence in the tutorial section about createdb: Database names must have an alphabetic first character and are limited to 63 characters I wondered - really characters? shouldn't it be bytes? I just tested - creating a database by using German umlauts let me get sure - it are bytes not characters. Here is the patch with the correction - I just changed the word characters into bytes. Susanne -- Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.com diff --git a/doc/src/sgml/start.sgml b/doc/src/sgml/start.sgml index 766dd7e..4275bf8 100644 --- a/doc/src/sgml/start.sgml +++ b/doc/src/sgml/start.sgml @@ -242,7 +242,7 @@ createdb: database creation failed: ERROR: permission denied to create database You can also create databases with other names. productnamePostgreSQL/productname allows you to create any number of databases at a given site. Database names must have an -alphabetic first character and are limited to 63 characters in +alphabetic first character and are limited to 63 bytes in length. A convenient choice is to create a database with the same name as your current user name. Many tools assume that database name as the default, so it can save you some typing. To create -- 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] psql \dt and table size
Hello Bernd, On 21.03.2011 18:44, Bernd Helmle wrote: Attached minor patch extends \dt to use pg_table_size() starting with PostgreSQL 9.0, not sure if we backport such changes though. It would be interesting for 9.1, however. As I already told you: I tested and it worked. The code looks correct to me. You just should send the code to a beauty farm - the wrinkles (braces) could get placed better also it could be more. :) Susanne -- Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.com -- 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] Collations versus user-defined functions
On 12.03.2011 18:17, Tom Lane wrote: Does the SQL standard have anything to say on the matter, or is there a precedent in the behavior of TSQL or other DBMSes? Tom, SQL standard let it open for implementers. The other DBMS - for which I am/was collation expert - takes afair the database/schema collation for functions/procedures - no individual collation. Just believe me - there is tons of user complain feedback on this topic. I really can't recommend doing it same way. My experience is that users want to use own collations in functions too. Susanne -- Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.com -- 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] Theory of operation of collation patch
On 07.03.2011 17:43, Tom Lane wrote:
because two expressions that are equal() must necessarily have the same
collation
property.
Peter, Tom,
I am not able to see this.
If 'abc' == 'abc' is not collation depending at all. It is only
encoding depending.
Collation is only needed for upper(), lower() and sorting.
Means it tells if e.g. upper('i') will get Y or I.
It tells if the German s-umlaut will be sorted together with 's' or
after 'z'.
Btw. the follows on implementing collations will be different -
and I hope Peter is aware of it.
My experience is that a huge follow will be that users will complain
that the
sorting isn't correct even when it is correct.
Susanne
--
Susanne Ebrecht - 2ndQuadrant
PostgreSQL Development, 24x7 Support, Training and Services
www.2ndQuadrant.com
--
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] German Ladies start translation project
On 05.03.2011 20:09, Heikki Linnakangas wrote: So the number of lines has roughly doubled since, and about a quarter of the 7.3 lines have changed. Heikki, Yeah. Additionally, German language vocabulary changed in computer area. E.g. today download is an official German word - ten years ago it wasn't. Susanne -- Susanne Ebrecht Bielefeld -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] German Ladies start translation project
Hello, I just wanted to inform you that Cornelia and me start the project to translate and publish the documentation German. Means the project will have a really high women concentration at the beginning :) pgsql-www suggested to take postgresql.de for publishing. I thought it is a great idea and so we will do it. Conny and me are involved in that domain anyway. Of course everybody is allowed helping us. We are on the way to set up all systems. We will keep it simple - without much graphical gadgets. We will take the original docs from source code after compiled as html. And on new release diff will get our friend. Why are we so mad? Peter once translated the whole docs and published a book. Afair it was for PostgreSQL 7.2 or 7.3. Google got much more aggressive on language and translation topic. When I take a German browser and Google for PostgreSQL + specific detail - then I first get the old Peter docs and after that I get the original postgresql.org docs - but - automatically translated from Google into German. Believe me - this translation are sometimes really worse. For me this means - it is finally time to translate / update old Peter docs. Peter and me think - just translate all again is faster then taking and checking his old texts. I am fully back - and of course I needed something reasonable todo - I know translating docs will get a life time project. I asked Cornelia if she wants to help because she already wrote a PostgreSQL book before Peter and she has lots of experiences with translations - She is involved in PHP doc translations too. She immediately said yes. As I said - we are on the way to set up all what we need on postgresql.de. Susanne -- Susanne Ebrecht Bielefeld -- 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] Determining client_encoding from client locale
On 17.01.2011 20:18, Peter Eisentraut wrote: That may be worth investigating, but I don't think it's related to the present patch. As I already said - not at all. The patch was ok for me. Susanne -- Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.com -- 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] Determining client_encoding from client locale
On 14.01.2011 20:12, Peter Eisentraut wrote: I have adjusted your old patch for the current tree, and it seems to work. I think it was just forgotten last time because the move to PQconnectdbParams had to happen first. But I'll throw it back into the ring now. Hello, maybe i missed pre-discussion but ... I miss considering auto-detect of file encoding. A simple example: $ psql -f dump.sql db What happens when dump.sql is written by using another encoding? I just would expect that when client encoding is detected by automatism that it also will be detected when I use files. My own experience from the others is that users more often forget to think about encoding when they deal with files as when they type in the client. Anyway, the code itself seems ok. I just would recommend to document that the client encoding should be checked from the user anyway. Just to make sure that it is not our fault, when there is a libc bug. Just my 2ct, Susanne -- Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.com -- 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] Determining client_encoding from client locale
On 17.01.2011 14:26, Peter Geoghegan wrote: On 17 January 2011 12:58, Susanne Ebrechtsusa...@2ndquadrant.com wrote: Hello, maybe i missed pre-discussion but ... I miss considering auto-detect of file encoding. A simple example: $ psql -f dump.sql db What happens when dump.sql is written by using another encoding? That doesn't tend to be much of a problem in practice because pg_dump will have the dump SET client_encoding as appropriate from the DB encoding. Ok, naming it dump.sql was confusing. My fault. I didn't thought about pg_dump dump files here. I more thought about files that came out of editors using mad encoding and maybe then also were created on Windows and then copied to Unix for import. Written on little endian, copied to big endian and so on. Susanne -- Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.com -- 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] [PATCHES] extension for sql update
Bruce Momjian wrote: Robert Treat wrote: On Saturday 12 August 2006 16:16, David Fetter wrote: On Fri, Aug 11, 2006 at 05:11:03PM -0500, Jim C. Nasby wrote: On Fri, Aug 11, 2006 at 10:59:45AM -0400, Bruce Momjian wrote: Peter Eisentraut wrote: Bruce Momjian wrote: Are we sure we don't want the patch for a non-subquery version of SET ROW for 8.2? o Allow UPDATE tab SET ROW (col, ...) = (...) for updating multiple columns It seems to be moderately useful as a notational convenience for now. Is it too hard to rip it back out once the full row support arrives? That seems speculation at best anyway. That's what I was thinking. Glad someone else replied. ;-) If you're looking for votes, +1. I'll gladly take a subset of the SQL standard UPDATE table SET (...) = (...) over having nothing. +1 here, too. :) +1 I am working now to get this into 8.2. I am glad to read this. But what does it mean to me? Shall I change the patch someway? Susanne ---(end of broadcast)--- TIP 1: 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] [PATCHES] extension for sql update
Am Donnerstag, den 27.07.2006, 08:30 -0400 schrieb Tom Lane: Susanne Ebrecht [EMAIL PROTECTED] writes: ... We could provide the mixed update syntax and leave the typed row value expression for the next release. Do you agree? I don't really see the point --- the patch won't provide any new functionality in anything like its current form, because you can always just write the separate expressions in the simple one to one way. If we do offer the row-on-the-left syntax then people will try to put sub-selects on the right, and won't get anything beyond an unhelpful syntax error message. So my vote would be to leave it alone until we have a more complete implementation. Look at my intention, why I wrote this patch: In recent years I migrated many customers applications from oracle or informix to postgresql. Every time it was a very painful and annoying job to grep through the code of functions and the whole software, to find all updates and change them manually. Far ago at university, I learned both syntax as standard syntax. Example: set a=1, b=2, c=3 and set (a,b,c)=(1,2,3) I admit, I prefered the second form, too, when I only used informix and it seems also my customers do so. Still now, I never found this syntax with select statement. I am not sure if this is possible with informix or oracle. regards Susanne regards, tom lane signature.asc Description: This is a digitally signed message part
Re: [HACKERS] [PATCHES] extension for sql update
Am Mittwoch, den 26.07.2006, 16:58 -0400 schrieb Tom Lane: Susanne Ebrecht [EMAIL PROTECTED] writes: This is a cute hack, but it does only a small part of what I think the spec says. Thank you for compliment. In the first place, the SQL syntax is pretty clear that you can combine simple and multiple assignment in the same UPDATE: Ups, I asked about mixed syntax and I missunderstood the answer (I thougt there is nothing spezified about mixed syntax). But fixing this, seems not to be difficult. The patch doesn't do that, but it wouldn't be too hard to fix. The more serious problem is that assigned row ::= contextually typed row value expression and contextually typed row value expression is supposed to be pretty much anything that can generate a row. The patch as you have it provides nothing more than syntactic sugar for something people can do anyway. The reason people want this syntax is that they expect to be able to write, say, UPDATE mytab SET (foo, bar, baz) = (SELECT alpha, beta, gamma FROM othertab WHERE key = mytab.key); and with something like that you can't break apart the row-valued expression in the grammar. So in reality the feature has to propagate much further into the backend than this. This seems to be difficult and I'm not sure this could be done until feature freeze. We could provide the mixed update syntax and leave the typed row value expression for the next release. Do you agree? regards Susanne Ebrecht signature.asc Description: This is a digitally signed message part
Re: [HACKERS] 8.2 features?
Am Freitag, den 14.07.2006, 16:26 +0200 schrieb Bernd Helmle: --On Freitag, Juli 14, 2006 01:23:11 +0200 Peter Eisentraut [EMAIL PROTECTED] wrote: . multiple values clauses for INSERT Susanne Ebrecht [EMAIL PROTECTED] was last heard to work on it. Updates, Susanne? I've talked to Susanne today and she's just back from hospital and not available online until next week. She was working on the SET (col1, col2) = (val1, val2) syntax for UPDATE commands. Don't know what the status is on this, though. Thanks Peter and Bernd for your postings. I'am working on update table set (col1, col2, ...) = (val1, val2, ...), (colx, coly, ...) = (valx, valy, ...), ... I hope, it will be finished this week. Most of work is done. Susanne signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
