Re: [HACKERS] Weird type selection choice
I wrote: I noticed this problem in 8.2 and 8.3: pei=# select mod( trunc( 1 ), 2 ); ERROR: 42883: function mod(double precision, integer) does not exist LINE 1: select mod( trunc( 1 ), 2 ); ^ I suppose there will be little interest in including the obvious solution, namely CREATE FUNCTION pg_catalog.trunc(int) RETURNS int AS $$ SELECT $1; $$ LANGUAGE SQL STRICT IMMUTABLE; into PostgreSQL. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] Visibility map thoughts
Jeff Davis wrote: On Mon, 2007-11-05 at 22:45 +, Heikki Linnakangas wrote: 1) Do as you say above. What are some of the cost trade-offs here? It seems that frequent VACUUM FREEZE runs would keep the visibility map mostly full, but will also cause more writing. I suppose the worst case is that every tuple write needs results in two data page writes, one normal write and another to freeze it later, which sounds bad. Maybe there's a way to try to freeze the tuples on a page before it's written out? It would also create more WAL traffic, because freezing tuples needs to be WAL-logged. The thought crossed my mind, but I couldn't think of any reason that would need to be logged. Of course you're right, and the comments explain it well. 5) Have a more fine-grain equivalent of relfrozenxid. For example one frozenxid per visibility map page, so that whenever you update the visibility map, you also update the frozenxid. To advance the relfrozenxid in pg_class, you scan the visibility map and set relfrozenxid to the smallest frozenxid. Unlike relfrozenxid, it could be set to FrozenXid if the group of pages are totally frozen. Wouldn't that still require WAL traffic? Otherwise how can you guarantee that the FrozenXid hits disk before TruncateCLOG truncates the old xmin away? Updating the fine-grain frozenxid would still need to be WAL-logged. But it would be lot less frequent than aggressively freezing tuples. Compared to the idea of having a separate bitmap or two bits per tuple in one data structure, you wouldn't necessarily have to freeze tuples to advance it, you could just observe what the smallest xid on a group of pages is. Like regular lazy vacuum does right now for relfrozenxid, just more fine-grained. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Weird type selection choice
Peter Eisentraut wrote: I wrote: I noticed this problem in 8.2 and 8.3: pei=# select mod( trunc( 1 ), 2 ); ERROR: 42883: function mod(double precision, integer) does not exist LINE 1: select mod( trunc( 1 ), 2 ); ^ I suppose there will be little interest in including the obvious solution, namely CREATE FUNCTION pg_catalog.trunc(int) RETURNS int AS $$ SELECT $1; $$ LANGUAGE SQL STRICT IMMUTABLE; It does sound totally useless... Why would you run a query like that in the first place? It seems like a useless query as it is. Is there a bigger story behind it? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Bug: --with-libxml does not take a location
Josh, did you try to set XML2_CONFIG prior to ./configure? I _am_ on Mac OS X 10.4.10, and using (in my particular case) $ export XML2_CONFIG=/usr/local/bin/xml2-config as well as --with-libraries=/usr/lib/:/usr/local/lib/ --with-includes=/usr/include/:/usr/local/include/ seems to work. PostgreSQL 8.3beta2 compiles without showing xml-related problems; I even peeked inside the Makefile to see if everything looked o.k. -- it does, AFAICS. Haven't found the time to test the installation, though. However, I'm using a different setup! I assume you are using the binary package from here: http://www.explain.com.au/oss/libxml2xslt.html. Instead of following the framework-approach you are referring to, I compiled and installed both the libxml2- and libxslt-libraries myself and put it to /usr/local. This leaves OS X's built in libraries untouched, and it gives you enough flexibility to use common *nix software more or less out of the box. (No Darwinports or Fink stuff or whatever involved on my side, only Apple's Xcode tools...) libxml2-2.6.30 works well with Perl and xml::libxml, as well as with R and the associated XML-package, and it doesn't seem to break anything, so in general this strategy works on OS X. On a related side note: configuring pg8.3b2 with a libxslt other than the system library in /usr fails on OS X, due to the fact that configure doesn't give us a XSLT_CONFIG variable ... Hope this helps, please keep us informed. Joerg Beyer ./configure --with-libxml does not accept a location argument. This makes it impossible to configure 8.3 with LibXML on the Mac, because I can't upgrade the main libxml without breaking something, and ./configure doesn't let me specify an alternate location. --with-libxml should accept a library location. --Josh Jörg Beyer PHILIPPS-University Marburg Dept. of Psychology Germany ---(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] Weird type selection choice
Peter Eisentraut wrote: Am Mittwoch, 7. November 2007 schrieb Heikki Linnakangas: Peter Eisentraut wrote: I wrote: I noticed this problem in 8.2 and 8.3: pei=# select mod( trunc( 1 ), 2 ); ERROR: 42883: function mod(double precision, integer) does not exist LINE 1: select mod( trunc( 1 ), 2 ); ^ I suppose there will be little interest in including the obvious solution, namely CREATE FUNCTION pg_catalog.trunc(int) RETURNS int AS $$ SELECT $1; $$ LANGUAGE SQL STRICT IMMUTABLE; It does sound totally useless... Why would you run a query like that in the first place? It seems like a useless query as it is. Is there a bigger story behind it? The 1 is substituted from somewhere else. If the value happens to be, say, 1.5, it works, but not with 1 or 2. Maybe as a workaround these are useful: alvherre=# select mod( trunc( 1.0 ), 2 ); mod - 1 (1 fila) alvherre=# select mod( trunc( 1::numeric ), 2 ); mod - 1 (1 fila) -- Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 18.1, W 73º 13' 56.4 Bob [Floyd] used to say that he was planning to get a Ph.D. by the green stamp method, namely by saving envelopes addressed to him as 'Dr. Floyd'. After collecting 500 such letters, he mused, a university somewhere in Arizona would probably grant him a degree. (Don Knuth) ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] A small rant about coding style for backend functions
Gregory Stark wrote: Brendan Jurd [EMAIL PROTECTED] writes: They are clear, useful and easy to understand. [1] http://www.python.org/dev/peps/pep-0007/ [2] http://www.python.org/dev/peps/pep-0008/ I didn't look at the second but the first at least is a good example of a style guide which is *not* useful. It's dominated by discussions of white-space and other formatting issues. Actually it is excellent guide because we use most of the same rules. (PEP 8 is about code style for code written in Python) -- Alvaro Herrerahttp://www.advogato.org/person/alvherre I'm always right, but sometimes I'm more right than other times. (Linus Torvalds) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Visibility map thoughts
On Tue, Nov 6, 2007 at 8:18 AM, in message [EMAIL PROTECTED], Heikki Linnakangas [EMAIL PROTECTED] wrote: The indexam API needs to be modified as well, because there's currently no API to return index tuples from an index. I know this is tangential, but expanding the types of selection criteria which can be applied to index entries (beyond equality and range tests) might fall out of this, yes? -Kevin ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Weird type selection choice
Peter Eisentraut [EMAIL PROTECTED] writes: Am Mittwoch, 7. November 2007 schrieb Heikki Linnakangas: Why would you run a query like that in the first place? It seems like a useless query as it is. Is there a bigger story behind it? The 1 is substituted from somewhere else. Seems like textual substitution is not the optimal approach for such a thing anyway --- why aren't they using a parameter? This is hardly the only gotcha, as an unadorned numeric literal might be taken as either int, bigint, or numeric depending on its value. I am sure there are contexts in which a bigint might cause some surprising choices. If they really want to stick with textual substitution, an explicit cast inserted into the query seems the safest bet. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] A small rant about coding style for backend functions
On 11/8/07, Bruce Momjian [EMAIL PROTECTED] wrote: The problem is that a full list would be harder to understand than just looking at the existing code and following it, or taking suggestions from us as we review the patch. What makes you say it would be necessarily harder to understand? That seems strange to me. Isn't that a bit like saying that the Postgres developers' FAQ is harder to understand than just asking the question on -hackers? What I'm talking about isn't weird. Large collaborative projects often have style guides. To take an example, Python has one for C code [1] and another for Python code [2]. They are clear, useful and easy to understand. [1] http://www.python.org/dev/peps/pep-0007/ [2] http://www.python.org/dev/peps/pep-0008/ Regards, BJ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Test lab
On Wed, 7 Nov 2007, Hannu Krosing wrote: To be really useful, we should always run general system monitoring alongside DB test runs, so we can see, and also later look up, where the bottleneck are. The way the DBT-2 tests run involves spawning off the relevant monitoring tools (iostat, vmstat, etc.) so that they write to a set of files. When the test is over those process are killed and a Perl script sorts through everything, drawing graphs and such using tools like gnuplot. That particular model, where the benchmark drives the data collection, makes it very easy to create graphs on a consistant time scale with application-specific results (like transactions per second). But it also requires that every application that wants to monitor in this area have its own code. There's certainly some value to something that instead monitors all the time in the background, and then individual applications can just ask for the period of time they're interested in rather than having their own monitoring code. The main issue I've run into is that when you're actually running a benchmark, the level of monitoring you want can be smaller than what you may want to leave running all the time. For example, I run iostat at 1 second intervals for some tests, because if you average on a longer basis you miss how big the fsync spike is when checkpoints happen. But it may not make sense to always have the system monitoring at 1 second resolution. I guess we (Skype DB team) could help to set something up on test lab machines as we have been doing it on production machines for a few years. I'd be curious to find out more about what you're doing. I've been fighting this particular problem on my own mini-lab for a while now, and it's pretty obvious to me that there's value to producing a more general solution to how to handle this sort of monitoring. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] A small rant about coding style for backend functions
Brendan Jurd wrote: On 11/6/07, Bruce Momjian [EMAIL PROTECTED] wrote: I understand your suggestions but it seems there would be too many individual items to be readable. Can you suggest a full list so we can get an idea of how long it would be? If the body of material on writing good Postgres code becomes so comprehensive that it doesn't all fit on one page: a) I would see that as a positive! b) We can of course split it up into sub-articles. I can't realistically suggest a full list since I am not an experienced Postgres hacker. But I would hope for, as a minimum: * the stuff about good GETARG style, * something about using ereport() effectively, and writing localization-friendly messages, * some actual coding style guidelines. The problem is that a full list would be harder to understand than just looking at the existing code and following it, or taking suggestions from us as we review the patch. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Segmentation fault using digest from pg_crypto
Marko Kreen wrote: On 11/6/07, Bruce Momjian [EMAIL PROTECTED] wrote: Alvaro Herrera wrote: Tom, how about putting a note about that into next 8.2 minor release notes? (8.3 too?) Something like You need to refresh pgcrypto functions, because since rel 8.2 the code depends on functions being tagged STRICT. Seems 8.2.5 was released without this release notes mention, but we haven't gotten any complaints about it so perhaps we don't need to add anything. Huh, I see exactly that complaint above. My point is that we can't mention it in the release notes until 8.2.6. Will there still be people who are having an issue with it who haven't found the problem already? And if we put it in 8.2.6, it really was effective for 8.2 so we just mention it in 8.2.6 and say it applies to 8.2.X too? We know that only few people have found the problem, because there is no way for them to guess what the fix should be by themselves, without consulting postgres lists. And I suspect most of the people who have not found out about the bug would still like to fix it in their setup, as crashing database is not fun. If only they knew about the problem... OK, should we add a mention in the 8.2.6 release notes or put it in the 8. notes and figure if someone is upgrading they will read the 8.2 notes? What would the description be? -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Bug: --with-libxml does not take a location
Maybe except --with-tcl --with-tclconfig=DIRECTORY although that's not exactly what you were referring to, of course. Anyway, I think the OS X case could be worth to keep the design question in mind. Speaking as a not very experienced user of 'make' and friends, I'm appreciating --with-featurefoo-config=DIR options (or setting related environment variables), because it makes it easier and more comprehensible for me to get the whole thing running. Cheers Joerg Andrew Dunstan wrote: None of our --with-featurefoo options takes an argument, BTW. That at least isn't a bug, it's by design. Jörg Beyer PHILIPPS-University Marburg Dept. of Psychology Germany ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] interval * numeric operator
There are interval * double precision operators (both ways) but none for interval * numeric. Adding this would make sense since interval is now optionally stored as fixed-point internally. Any objections to adding this in 8.4? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] A small rant about coding style for backend functions
Brendan Jurd [EMAIL PROTECTED] writes: They are clear, useful and easy to understand. [1] http://www.python.org/dev/peps/pep-0007/ [2] http://www.python.org/dev/peps/pep-0008/ I didn't look at the second but the first at least is a good example of a style guide which is *not* useful. It's dominated by discussions of white-space and other formatting issues. The only points in this style guide which seem at all useful is the bits near the beginning about not using GCC extensions which hardly needs stating... to the extent that it's even true. None of these points in here seem at all analogous to the important kind of style details like what Tom was pointing out about using GETARG_* at the top of your function to make the argument types clear. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Weird type selection choice
Am Mittwoch, 7. November 2007 schrieb Heikki Linnakangas: Peter Eisentraut wrote: I wrote: I noticed this problem in 8.2 and 8.3: pei=# select mod( trunc( 1 ), 2 ); ERROR: 42883: function mod(double precision, integer) does not exist LINE 1: select mod( trunc( 1 ), 2 ); ^ I suppose there will be little interest in including the obvious solution, namely CREATE FUNCTION pg_catalog.trunc(int) RETURNS int AS $$ SELECT $1; $$ LANGUAGE SQL STRICT IMMUTABLE; It does sound totally useless... Why would you run a query like that in the first place? It seems like a useless query as it is. Is there a bigger story behind it? The 1 is substituted from somewhere else. If the value happens to be, say, 1.5, it works, but not with 1 or 2. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [pgsql-www] tribble.postgresql.org - planned maintenance downtime
Stefan Kaltenbrunner wrote: Hi all! There will be planned downtime on tribble.postgresql.org Nov 7(tomorrow) from 11:30-12:00 GMT(estimated) affecting the following services: cvs.postgresql.org wwwmaster.postgresql.org www.pgadmin.org doxygen.postgresql.org Downtime is necessary to implement several changes to the installed firmware levels and bios settings after the unplanned outage yesterday. I would advise to hold off on commits to the affected repositories until I give an explict it's done. work completed and all services back up. regards Stefan ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Test lab
Ühel kenal päeval, P, 2007-11-04 kell 13:02, kirjutas Greg Smith: On Sat, 3 Nov 2007, Stefan Kaltenbrunner wrote: there is the various dbt workloads,sysbench, jans tpc-w implementation, hell even pgbench The DBT workloads are good for simulating disk-bound operations, but I don't think they're sufficient by themselves for detecting performance regressions because of that. TPC-W might serve to better simulate when things are CPU-bound, that particular implementation felt a bit out of date when I tried using it and I think it could use a round of polishing. To be really useful, we should always run general system monitoring alongside DB test runs, so we can see, and also later look up, where the bottleneck are. At least CPU (system, user, io wait, ), RAM and disk usage should be monitored continuously alongside benchmark runs. I guess we (Skype DB team) could help to set something up on test lab machines as we have been doing it on production machines for a few years. --- Hannu ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_resetxlog output clarification
Am Dienstag, 25. September 2007 schrieb Simon Riggs: Peter Eisentraut [EMAIL PROTECTED] writes: First log file ID for new XLOG: First log file segment for new XLOG: Perhaps after reset would be better than for new XLOG. I like this better. I have made the change. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] pg_statistic forced values
Hi, It is well known that in some instances the Postgresql will make estimates of the number of distinct values in a table that can be quite far off reality. This then has a tendency to make the planner lean towards unsavory plans (read: seqscans) because it estimates the number of lines returned by a part of the request as being quite a lot more than they really are. The good solution would be to fix the estimator, but there has already been long discussions on this topic in the past years and apparently no consensus was found, with alternatives proposed fixing some cases where the current estimator is wrong but getting in trouble in others, or requiring quite a bit more CPU/memory/disk I/O to achieve their results (correct me if I'm wrong). There is a simple way to override this, which is to change the value present in pg_statistic, however it will be overwritten the next time ANALYZE (or VACUUM ANALYZE) is run. This thus requires adding updates to this value every time a request that might be fooled by it is executed, which is cumbersome, and does not facilitate updates of this value (especially with positive values of stadistinct). It seems to me it would be a good idea to be able to store a forced value for stadistinct in pg_attribute (with optionally some clauses to set/change/reset it in CREATE TABLE, ALTER TABLE ADD COLUMN and ALTER TABLE ALTER COLUMN, in a way similar to the STATISTICS clauses). Alternatively, it could be a simple boolean to just say don't update stadistinct. Or did I miss something and this already exists somewhere? If not, are there any comments or suggestions regarding implementing this? Thanks, Jacques. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Visibility map thoughts
On Wed, Nov 7, 2007 at 3:13 PM, in message [EMAIL PROTECTED], Heikki Linnakangas [EMAIL PROTECTED] wrote: Kevin Grittner wrote: On Tue, Nov 6, 2007 at 8:18 AM, in message [EMAIL PROTECTED], Heikki Linnakangas [EMAIL PROTECTED] wrote: The indexam API needs to be modified as well, because there's currently no API to return index tuples from an index. I know this is tangential, but expanding the types of selection criteria which can be applied to index entries (beyond equality and range tests) might fall out of this, yes? What else so you have in mind? With index-only-scans, it would sometimes make sense to do a full index scan. I wasn't thinking of anything else on that front myself. I know this issue on this thread has come up at least one or two other times lately: http://archives.postgresql.org/pgsql-performance/2007-08/msg00113.php I know it's a largely independent issue, but your comment about the API not giving access to the index tuples echoed comments regarding what it would take to allow optimizations in this area. -Kevin ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] New tzdata available
Hi, ftp://elsie.nci.nih.gov/pub/tzdata2007i.tar.gz Per announcement: ...is now available; this reflects changes for Cuba and Syria circulated earlier this week on the time zone mailing list. There are no code changes, so there's no tzcode2007i; tzcood2007h remains current. Regards, -- Devrim GÜNDÜZ PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Visibility map thoughts
Kevin Grittner wrote: On Tue, Nov 6, 2007 at 8:18 AM, in message [EMAIL PROTECTED], Heikki Linnakangas [EMAIL PROTECTED] wrote: The indexam API needs to be modified as well, because there's currently no API to return index tuples from an index. I know this is tangential, but expanding the types of selection criteria which can be applied to index entries (beyond equality and range tests) might fall out of this, yes? What else so you have in mind? With index-only-scans, it would sometimes make sense to do a full index scan. I wasn't thinking of anything else on that front myself. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(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
[HACKERS] Throw error and ErrorContext question.
Hi,
Regarding the function parameter ref TODO:
I am trying to catch and copy an error to be re-thrown later.
I have the following questions:
1. Is the catch part in the following safe?
2. How do I re-throw the copied error when I am not in ErrorContext anymore?
I cannot use ReThrowError because of Assert.
3. If I have to use something like: ereport(ERROR,mysaved_error-message ...
mysaved_error-detail .. );
then how do I FreeErrorData(mysaved_error) after calling the ereport
above?
First:
MemoryContext parseMemCtx = CurrentMemoryContext;
Then:
/* Try to identify as a once-qualified column */
PG_TRY();
{
node = qualifiedNameToVar(pstate, NULL, name1, name2, true,
cref-location);
/* status set to 0 or 1 */
qualified_status = (node != NULL);
}
PG_CATCH();
{
/* copy this error for later use */
errorMemCtx = CurrentMemoryContext;
MemoryContextSwitchTo(parseMemCtx);
qualifiedErrData = CopyErrorData();
FlushErrorState();
MemoryContextSwitchTo(errorMemCtx);
/* status is set to error */
qualified_status = 2;
}
PG_END_TRY();
Gevik Babakhani
PostgreSQL NL http://www.postgresql.nl
TrueSoftware BV http://www.truesoftware.nl
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] fulltext parser strange behave
Pavel Stehule [EMAIL PROTECTED] writes: I am writing tsearch2 wrapper and I testing functionality. I found some little bit strange on default parser. It can't parse tags with numbers: Well, the state machine definitely thinks that tag names should contain only ASCII letters (with possibly a leading or trailing '/'). Given the HTML examples I suppose we should allow non-first digits too. Is there anything else that should be considered a tag? What about dash and underscore for instance? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Feature Request: inline comments
Whilst reading http://www.postgresql.org/docs/8.2/interactive/sql-comment.html I came across this user comment: Ricardo Bánffy 04 Sep 2007 18:15:44 It is a pretty obvious suggestion I bet was made many, many times before, but it would be very useful if you could create comments while creating the objects themselves, like CREATE TABLE FOO ( ID INTEGER NOT NULL PRIMARY KEY COMMENT 'The ID', VALUE VARCHAR(10) COMMENT 'The value', ) COMMENT 'The table'; This would be a good thing as it would make documenting schemas more in-your-face and less prone to forgetting (ie, atm, if you do want to comment on rows you effectively wind up with two table definitions (kinda)). Perhaps this is a small enough add to make it into 8.3? -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Throw error and ErrorContext question.
Gevik Babakhani [EMAIL PROTECTED] writes: I am trying to catch and copy an error to be re-thrown later. This is certainly not the right way to go about solving your problem. If you need to refactor some of the column lookup routines to make this patch work, then do so, but don't try to make an already-thrown error not be an error. (One good reason for that is that you don't really know what error you are catching --- it might be a report of some low-level problem such as out-of-memory, for instance.) The pattern you might want to follow is adding a noError boolean parameter to functions you want to be able to get failure returns back from. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Feature Request: inline comments
CaT [EMAIL PROTECTED] writes: It is a pretty obvious suggestion I bet was made many, many times before, but it would be very useful if you could create comments while creating the objects themselves, like CREATE TABLE FOO ( ID INTEGER NOT NULL PRIMARY KEY COMMENT 'The ID', VALUE VARCHAR(10) COMMENT 'The value', ) COMMENT 'The table'; This seems like a fairly bad idea to me, because it converts your table definitions into proprietary syntax. Heaven help you trying to load the above into any other database. With a separate COMMENT ON command, at least you have a fighting chance of ignoring the errors and pressing on. Perhaps this is a small enough add to make it into 8.3? Feature freeze was six months ago, and no this wouldn't be a small add even if it was the best idea since sliced bread. regards, tom lane ---(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] fulltext parser strange behave
Tom Lane wrote: Pavel Stehule [EMAIL PROTECTED] writes: I am writing tsearch2 wrapper and I testing functionality. I found some little bit strange on default parser. It can't parse tags with numbers: Well, the state machine definitely thinks that tag names should contain only ASCII letters (with possibly a leading or trailing '/'). Given the HTML examples I suppose we should allow non-first digits too. Is there anything else that should be considered a tag? What about dash and underscore for instance? The docs say we specifically accept HTML tags. Are we really just accepting anything that is a string of ASCII letters as the tag name? Then we should adjust the docs. foo and foo1234 are not HTML tags. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Feature Request: inline comments
On Wed, Nov 07, 2007 at 06:32:53PM -0500, Tom Lane wrote: CaT [EMAIL PROTECTED] writes: It is a pretty obvious suggestion I bet was made many, many times before, but it would be very useful if you could create comments while creating the objects themselves, like CREATE TABLE FOO ( ID INTEGER NOT NULL PRIMARY KEY COMMENT 'The ID', VALUE VARCHAR(10) COMMENT 'The value', ) COMMENT 'The table'; This seems like a fairly bad idea to me, because it converts your table definitions into proprietary syntax. Heaven help you trying to load the above into any other database. With a separate COMMENT ON command, at least you have a fighting chance of ignoring the errors and pressing on. Well, in a dump of the DB, you could have them as COMMENT ON. Otherwise I /think/ this should do it in vim at least: :%s/ COMMENT '\([^']*''\)*[^']*'// It's not a perfect regex (though I think it could be made to hand E'' escaping) but it'll do for most comments. Perhaps this is a small enough add to make it into 8.3? Feature freeze was six months ago, and no this wouldn't be a small add even if it was the best idea since sliced bread. Fair cop. -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby ---(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] Throw error and ErrorContext question.
Thank you Tom. I have considered a noError boolean too. but please considered the following: step 1: call qualifiedNameToVar(noError = true), which generates an error but gets suppressed by noError parameter. step 2: process function parameter name for funct1.param1, check funct1 == the name of the current function, which funct1 is unknown/ambiguous (the name of the current function was func for example). In the case above I thought I somehow re-throw the error that was originally generated at step 1. Regards, Gevik. Gevik Babakhani PostgreSQL NL http://www.postgresql.nl TrueSoftware BV http://www.truesoftware.nl -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane Sent: Thursday, November 08, 2007 12:25 AM To: Gevik Babakhani Cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Throw error and ErrorContext question. Gevik Babakhani [EMAIL PROTECTED] writes: I am trying to catch and copy an error to be re-thrown later. This is certainly not the right way to go about solving your problem. If you need to refactor some of the column lookup routines to make this patch work, then do so, but don't try to make an already-thrown error not be an error. (One good reason for that is that you don't really know what error you are catching --- it might be a report of some low-level problem such as out-of-memory, for instance.) The pattern you might want to follow is adding a noError boolean parameter to functions you want to be able to get failure returns back from. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] fulltext parser strange behave
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: Well, the state machine definitely thinks that tag names should contain only ASCII letters (with possibly a leading or trailing '/'). Given the HTML examples I suppose we should allow non-first digits too. Is there anything else that should be considered a tag? What about dash and underscore for instance? The docs say we specifically accept HTML tags. Are we really just accepting anything that is a string of ASCII letters as the tag name? Then we should adjust the docs. foo and foo1234 are not HTML tags. I don't think I want to try to maintain a list of exactly which identifiers are considered valid tag names ... and if I did, I wouldn't put it into the parser. It would be a dictionary's job to tell valid from invalid tag names, no? I don't have a quarrel with that. But then we should be more clear about what we are recognizing. We could describe the thing as an HTML-like tag, possibly. I think the same probably goes for entities too. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] fulltext parser strange behave
On Wed, 7 Nov 2007, Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: Well, the state machine definitely thinks that tag names should contain only ASCII letters (with possibly a leading or trailing '/'). Given the HTML examples I suppose we should allow non-first digits too. Is there anything else that should be considered a tag? What about dash and underscore for instance? The docs say we specifically accept HTML tags. Are we really just accepting anything that is a string of ASCII letters as the tag name? Then we should adjust the docs. foo and foo1234 are not HTML tags. I don't think I want to try to maintain a list of exactly which identifiers are considered valid tag names ... and if I did, I wouldn't put it into the parser. It would be a dictionary's job to tell valid from invalid tag names, no? it'd be nice to know in dictionary the parser state, but I think it's too much knowledge for dictionary and the only possibility is to let foo1234 pass to dictionary. Currently we have three separate tokens. regards, tom lane Regards, Oleg _ Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru), Sternberg Astronomical Institute, Moscow University, Russia Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(495)939-16-83, +007(495)939-23-83 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Bug: --with-libxml does not take a location
Jörg Beyer wrote: Josh, did you try to set XML2_CONFIG prior to ./configure? I _am_ on Mac OS X 10.4.10, and using (in my particular case) $ export XML2_CONFIG=/usr/local/bin/xml2-config as well as --with-libraries=/usr/lib/:/usr/local/lib/ --with-includes=/usr/include/:/usr/local/include/ OK, thanks, I'll try that. --Josh ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Beta2 crash / create type + tsearch2
Tom Lane [EMAIL PROTECTED] [07-11-2007 05:24]: Jeff Davis [EMAIL PROTECTED] writes: I agree that a dump/restore from 8.2 with tsearch2 to 8.3 with built-in tsearch should not SIGSEGV. That's not what he did, though. Force-feeding contrib/tsearch2 into 8.3 will not work. That is what I did. It's dump what has generated these commands, not my ideas. Note: I don't have a problem with editing the dump if that's what is needed. cvs rm ...? -- Radosław Zieliński [EMAIL PROTECTED] pgp8H1nANlcVr.pgp Description: PGP signature
Re: [HACKERS] Feature Request: inline comments
CaT wrote: On Wed, Nov 07, 2007 at 06:32:53PM -0500, Tom Lane wrote: CaT [EMAIL PROTECTED] writes: It is a pretty obvious suggestion I bet was made many, many times before, but it would be very useful if you could create comments while creating the objects themselves, like CREATE TABLE FOO ( ID INTEGER NOT NULL PRIMARY KEY COMMENT 'The ID', VALUE VARCHAR(10) COMMENT 'The value', ) COMMENT 'The table'; This seems like a fairly bad idea to me, because it converts your table definitions into proprietary syntax. Heaven help you trying to load the above into any other database. With a separate COMMENT ON command, at least you have a fighting chance of ignoring the errors and pressing on. Well, in a dump of the DB, you could have them as COMMENT ON. Otherwise I /think/ this should do it in vim at least: :%s/ COMMENT '\([^']*''\)*[^']*'// It's not a perfect regex (though I think it could be made to hand E'' escaping) but it'll do for most comments. No it won't. There's dollar quoting to think of, and multiline comments. It all looks like clutter to me anyway. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] fulltext parser strange behave
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: Well, the state machine definitely thinks that tag names should contain only ASCII letters (with possibly a leading or trailing '/'). Given the HTML examples I suppose we should allow non-first digits too. Is there anything else that should be considered a tag? What about dash and underscore for instance? The docs say we specifically accept HTML tags. Are we really just accepting anything that is a string of ASCII letters as the tag name? Then we should adjust the docs. foo and foo1234 are not HTML tags. I don't think I want to try to maintain a list of exactly which identifiers are considered valid tag names ... and if I did, I wouldn't put it into the parser. It would be a dictionary's job to tell valid from invalid tag names, no? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Throw error and ErrorContext question.
Gevik Babakhani [EMAIL PROTECTED] writes: I have considered a noError boolean too. but please considered the following: step 1: call qualifiedNameToVar(noError = true), which generates an error but gets suppressed by noError parameter. step 2: process function parameter name for funct1.param1, check funct1 == the name of the current function, which funct1 is unknown/ambiguous (the name of the current function was func for example). In the case above I thought I somehow re-throw the error that was originally generated at step 1. Yeah, you'd throw the same error number and message as that routine would have thrown, but matching that is not rocket science ;-). I don't see any value in trying to have only one instance of the ereport() call instead of two --- it's going to cost you *more* lines of code and *more* intellectual complexity to try to trap and re-throw the error than it will cost to just have two identical ereport() calls. Although quite frankly I don't see any need to be touching qualifiedNameToVar at all. It's already defined to return NULL if it doesn't find the name anyplace in the query, which seems to me to be what you want anyway. The only non-internal error it might raise is ambiguous name which is fine. That's an error condition, and the possibility that there is a function variable visible at an outer name scoping level doesn't make it not an error. The place where you need to be refactoring is probably in or around the transformWholeRowRef/ParseFuncOrColumn sequence. One thing that we need to think about is what is the priority of function-variable matching compared to implicit RTE creation. I'm inclined to think we should allow function variables to go first... regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
