[COMMITTERS] pgsql-server/src/backend/po hr.po
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/10/04 15:09:10 Modified files: src/backend/po : hr.po Log message: Translation update ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[COMMITTERS] pgsql-server/src bin/psql/po/es.po interfaces/ ...
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/10/04 15:13:16 Modified files: src/bin/psql/po: es.po src/interfaces/libpq/po: es.po Log message: Translation updates ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[COMMITTERS] pgsql-server/doc TODO
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/10/04 15:19:57 Modified files: doc: TODO Log message: Modify: < * Consider using MVCC to cache count(*) queries with no WHERE clause > * Use a fixed row count and a +/- count with MVCC visibility rules > to allow fast COUNT(*) queries with no WHERE clause(?) ---(end of broadcast)--- TIP 8: explain analyze is your friend
[COMMITTERS] pgsql-server/src backend/utils/adt/ruleutils.c ...
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/10/04 15:23:00 Modified files: src/backend/utils/adt: ruleutils.c src/backend/utils/cache: lsyscache.c src/include/utils: lsyscache.h Log message: Fix pg_get_constraintdef() to ensure CHECK constraints are always shown with required outer parentheses. Breakage seems to be leftover from domain-constraint patches. This could be smarter about suppressing extra parens, but at this stage of the release cycle I want certainty not cuteness. ---(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
[COMMITTERS] pgsql-server/ oc/src/sgml/libpq.sgml rc/interf ...
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/10/04 18:05:22 Modified files: doc/src/sgml : libpq.sgml src/interfaces/libpq: fe-exec.c Log message: Document the always-true-but-previously-undocumented fact that PQfnumber() will downcase the supplied field name unless it is double-quoted. Also, upgrade the routine's handling of double quotes to match the backend, in particular support doubled double quotes within quoted identifiers. Per pgsql-interfaces discussion a couple weeks ago. ---(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
[COMMITTERS] pgsql-server/src/backend/po es.po
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/10/04 19:50:20 Modified files: src/backend/po : es.po Log message: Translation update ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [COMMITTERS] pgsql-server/ oc/src/sgml/runtime.sgml rc/back ...
Tom Lane writes: > > If it's only honored by SQL functions, then it should probably be called > > check_sql_function_bodies. > > I thought about that while I was making the patch, but decided that it > would be a very un-forward-looking name. Someday we will probably have > syntax-checking validators for plpgsql, etc. The point of this feature is to avoid failures because of forward references in SQL code. A syntax-checking validator in anything but possibly plpgsql will not even look at SQL code, so a validator for a different language will only gain pain and confusion by respecting this parameter. Perhaps it needs to different name altogether, along the lines of "do not check SQL code in functions". -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [COMMITTERS] pgsql-server/ oc/src/sgml/libpq.sgml rc/interf ...
Tom Lane writes: > Document the always-true-but-previously-undocumented fact that PQfnumber() > will downcase the supplied field name unless it is double-quoted. Also, > upgrade the routine's handling of double quotes to match the backend, > in particular support doubled double quotes within quoted identifiers. Isn't that an instance of the same "buggy" behavior that the database name provided to libpq once exhibited, i.e., it should be removed? > Per pgsql-interfaces discussion a couple weeks ago. Could I request that technical decisions that are reached somewhere in the depth of threads on user-level mailing lists are posted to hackers before they are applied? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [COMMITTERS] pgsql-server/ oc/src/sgml/runtime.sgml rc/back ...
Peter Eisentraut <[EMAIL PROTECTED]> writes: > The point of this feature is to avoid failures because of forward > references in SQL code. A syntax-checking validator in anything but > possibly plpgsql will not even look at SQL code, so a validator for > a different language will only gain pain and confusion by respecting this > parameter. Perhaps it needs to different name altogether, along the lines > of "do not check SQL code in functions". Well, I'm certainly not wedded to the name "check_function_bodies", but I still feel that you're taking an overly narrow view of the future functionality of this switch. The existing reason for having the switch is not only to avoid forward-reference problems; it also is needed to avoid search-path problems (eg, if the function assumes "public" is in the search path, which it won't be during pg_restore). I think that issues like these are likely to arise for other sorts of checks than those on embedded SQL code. For example, it probably wouldn't be unreasonable for a validator for brand-X-language to try to check the existence of referenced functions, even if those functions are called from code that doesn't look much like SQL. We could use "check_sql_code" or some such, and it might be an accurate description of what the switch does today, but I think we'd end up having to either change the switch name or add more switches of the same kind in future to cover other checks that turn out to be not always applicable. I'd prefer to use a deliberately somewhat vague name to improve the odds that we don't have to do that. Would you like it better if the switch were called do_all_the_right_things_for_pg_dump? (That name is a bit facetious, but in terms of long-term behavior that's pretty much what I'm after.) regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [COMMITTERS] pgsql-server/ oc/src/sgml/libpq.sgml rc/interf ...
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Tom Lane writes: >> Document the always-true-but-previously-undocumented fact that PQfnumber() >> will downcase the supplied field name unless it is double-quoted. Also, >> upgrade the routine's handling of double quotes to match the backend, >> in particular support doubled double quotes within quoted identifiers. > Isn't that an instance of the same "buggy" behavior that the database name > provided to libpq once exhibited, i.e., it should be removed? Well, we can re-discuss it if you like. I'd have preferred that answer myself, but it didn't seem to be the winner in the pg-interfaces discussion. >> Per pgsql-interfaces discussion a couple weeks ago. > Could I request that technical decisions that are reached somewhere in the > depth of threads on user-level mailing lists are posted to hackers before > they are applied? As far as I'm concerned, pgsql-interfaces is an appropriate and sufficiently authoritative discussion forum for issues that only affect the interface libraries and not the backend. If we aren't willing to delegate, we might as well eliminate all the other lists and just have pgsql-hackers. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[COMMITTERS] pgsql-server/doc FAQ src/FAQ/FAQ.html
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/10/05 00:52:08 Modified files: doc: FAQ doc/src/FAQ: FAQ.html Log message: Update MySQL mention. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
