Re: [HACKERS] psql \d option list overloaded
Bruce Momjian wrote:
Alex J. Avriette wrote:
On Sun, Jan 04, 2004 at 07:59:02PM -0600, D. Dante Lorenso wrote:
Anything other than simple, short commands is a waste, IMHO. I can easily
remember SHOW DATABASES and SHOW TABLES and DESC table, because they
reflect
my intensions directly and 'make sense'.
What makes sense to me in csh doesn't make sense in a bourne shell.
You can't expect all applications to work correctly. I'd like to second
Peter's yep when asked if he could remember all the various \d*
commands. It really comes down to whether you're trying. New software
(even though you may have been using it for a year) requires some
adjustment.
OK, I will drop the idea. Thanks.
Bruce,
The idea is not without merit. What you are looking at is a way to get
this information as a query without having to know all the intricasies
of all the pg_* internals or duplicating complex queries. psql -E
shows you just how tricky this is. Secondly, if this information
changes in a release, then the end user has to rewrite all of the
queries to work. Being able to issue a query to the dbms and get the
information as a normal SQL result makes sense and is definately convenient.
The \d* commands work from psql but not from anywhere else.Try
getting the information from a PHP script by sending a \dS query. It
doesn't work. If the same queries were stored in the backend and
referenced by psql and also could be referenced by other scripts, this
would be a good thing and keep the work centralized. If the queries
were in the backend, the psql users could keep the \dS command but it
would call an internal function or execute a queried stored in the
system tables.
One option is to get the information via a function like
SELECT * FROM pg_info('tables');
SELECT * FROM pg_info('indexes');
psql -E would show the same query being executed for \dt
Another option if no one wanted a language construct, perhaps one option
would be to store the queries themselves in a table like pg_queries.
This also has the advantage of exposing the queries used so that they
can used as examples for other purposes.
++--+
|pg_info_type|pg_query |
++--+
|tables |SELECT n.nspname as Schema, c.relname |
||as Name, CASE c.relkind WHEN 'r' THEN |
||'table' WHEN 'v' THEN 'view' WHEN 'i' THEN|
||'index' WHEN 'S' THEN 'sequence' WHEN 's' |
||THEN 'special' END as Type, u.usename as|
||Owner FROM pg_catalog.pg_class c LEFT |
||JOIN pg_catalog.pg_user u ON u.usesysid = |
||c.relowner LEFT JOIN |
||pg_catalog.pg_namespace n ON n.oid = |
||c.relnamespace WHERE c.relkind IN ('r','')|
||AND n.nspname NOT IN ('pg_catalog', |
||'pg_toast') AND |
||pg_catalog.pg_table_is_visible(c.oid) |
||ORDER BY 1,2; |
++--+
|indexes |SELECT n.nspname as Schema, c.relname as|
||Name, CASE c.relkind WHEN 'r' THEN |
||'table' WHEN 'v' THEN 'view' WHEN 'i' THEN|
||'index' WHEN 'S' THEN 'sequence' WHEN 's' |
||THEN 'special' END as Type, u.usename as|
||Owner, c2.relname as Table FROM |
||pg_catalog.pg_class c JOIN|
||pg_catalog.pg_index i ON i.indexrelid = |
||c.oid JOIN pg_catalog.pg_class c2 ON |
||i.indrelid = c2.oid LEFT JOIN |
||pg_catalog.pg_user u ON u.usesysid = |
||c.relowner LEFT JOIN |
||pg_catalog.pg_namespace n ON n.oid = |
||c.relnamespace WHERE c.relkind IN ('i','')|
||AND n.nspname NOT IN ('pg_catalog', |
||'pg_toast') AND |
||pg_catalog.pg_table_is_visible(c.oid) |
||ORDER BY 1,2; |
++--+
Again, this is just food for thought. Perhaps it is a way to satisfy
both arguments.
Thomas
---(end of broadcast)---
TIP 8: explain analyze is your friend
[HACKERS] Translations in the distributions
The default installation in fedora does not work very well for non english people. For example. if I run psql and type COMMIT i get: dennis=# commit; WARNING: COMMIT: ingen transaktion p g while it should say dennis=# commit; WARNING: COMMIT: ingen transaktion pågår And those spaces in the first version are no spaces at all but some strange characters. However, I have the cvs version compiled and installed, and it seems to work just fine. Is this because pg has been fixed lately (I don't remember any such discussions) or something with the packaging, or something else. What I want is that future fedora/redhat versions work out of the box. Most people use distributions and it's no fun to translate postgresql if people are annoyed with the result :-) -- /Dennis Björklund ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Translations in the distributions
=?ISO-8859-1?Q?Dennis_Bj=F6rklund?= [EMAIL PROTECTED] writes: The default installation in fedora does not work very well for non english people. I seem to recall some discussion to the effect that the message catalog files have to be in the same encoding the database is using, because there's no provision in the backend for converting them on-the-fly. Peter E. would be the person to ask though. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Translations in the distributions
On Fri, 9 Jan 2004, Tom Lane wrote: I seem to recall some discussion to the effect that the message catalog files have to be in the same encoding the database is using, because there's no provision in the backend for converting them on-the-fly. Still, my cvs tree seems to work. The catalogues are still in latin1 and fedora still uses utf-8. So something seems to have made it work (probably Peter). I know we have had some discussions in the past but I've never really got the whole picture of the problem. In any way, now that distributions starts to change to utf-8, it puts greater demands on us since one encoding might not work as good anymore (it never really worked, but that is another issue). Maybe it all just works now and when redhat/fedora starts to use 7.4 all will be fine. All I want it to make sure that it works. If it's not working, it's something that I might spend some time on trying to fix. -- /Dennis Björklund ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Translations in the distributions
Am Freitag, 9. Januar 2004 08:08 schrieb Dennis Björklund: The default installation in fedora does not work very well for non english people. For example. if I run psql and type COMMIT i get: dennis=# commit; WARNING: COMMIT: ingen transaktion p g while it should say dennis=# commit; WARNING: COMMIT: ingen transaktion pågår Remember that gettext will automatically recode the strings depending on what it thinks is the display character set, determined via LC_CTYPE (of course, a useless concept for server software). After that, PostgreSQL's own client/ server recoding will happen. So somewhere along the line there something might get lost. Either the RPM package uses a different locale, or it has bugs in gettext or iconv. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Translations in distributions 2
I've made some tests to see what works and what does not. I downloaded pg 7.3.4 (which is more or less what is used in fedora) and current cvs. Both compiled with the same flags and run in the same way. pg 7.3.4 Running LC_ALL=sv_SE postmaster and LC_ALL=sv_SE.UTF-8 postmaster both produces messages with same encoding. pg 7.5 (cvs) Running LC_ALL=sv_SE postmaster and LC_ALL=sv_SE.UTF-8 postmaster produces messages with different encodings, either latin1 or utf-8 depending on the environment variable. The only conclusion I have so far is that something have indeed changed in pg after 7.3 and maybe in the future it will work a little better in fedora and other dists. The problems with client/server having different encodings still remains to be solved. That is probably solvable by simply translating the messages to client_encoding before sending. It does not sound very hard. The language used should however also be that of the client and it might need (a lot) more work. A last question. Why is --enable-nls needed? Most other programs default to that. -- /Dennis Björklund ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] psql \d option list overloaded
Hi, 2) (using information schema ... little better) SELECT table_name FROM information_schema.tables WHERE table_schema = 'public'; or ... ... I just looked at the information_schema. It is a very nice feature, but difficult to use in psql. I just wanted to see, what I can find here. After trying and rtfm I ended in '\d information_schema.*'. I get a very large page wich is quite unreadable. '\d' is normally very usable. It would be better not to show the view-definition. What if \d on views just show the column, type and attribute. \d+ would show the full view-definition. Tommi -- Dr. Eckhardt + Partner GmbH http://www.epgmbh.de ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Strand COPY from problem
Hi every one and Happy new year (this is my first post since 2004) I wanted to upgrade my system from 7.3.4 to 7.4. and fell on this: One of the databases I host doesn't load correctly. Let me explain: I first pg_dumpall (with the 7.4.1 version) using the 7.3.4 port; that works fine. The psql -f all.sql template1 on the 741 version to recreate every thing. 2 copy don't work. those tables both contain a large text column with text containing lots of \r\n ' . What's stange is that copy from stdin; obviously don't work but if I copy table to '/tmp/xxx.dat' in 7.3.4 and copy table from 'xxx.dat' in 7.4.1, it works fine... Could there but something wrong with from stdin? TIA for your help... -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] psql \d option list overloaded
Thomas Swan wrote: The \d* commands work from psql but not from anywhere else.Try getting the information from a PHP script by sending a \dS query. It doesn't work. If the same queries were stored in the backend and referenced by psql and also could be referenced by other scripts, this would be a good thing and keep the work centralized. If the queries were in the backend, the psql users could keep the \dS command but it would call an internal function or execute a queried stored in the system tables. leibnitz-mode I just independently had this idea, so I like it :-) /liebnitz-mode cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] with grant option for user groups.
Hi all, We are building security system for a project where the security is modeled based on the sql-92 GRANT/REVOKE statements. I was going through the documentation of postgresql related to GRANT/REVOKE statements. Following statement says that with grant option is not allowed to a user group. I would like to know what the reasons behind not implementing this kind of feature. If WITH GRANT OPTION is specified, the recipient of the privilege may in turn grant it to others. By default this is not allowed. Grant options can only be granted to individual users, not to groups or PUBLIC. http://developer.postgresql.org/docs/postgres/sql-grant.html I looked into ORACLE database also they don't support user groups, but they support roles. But even for roles with grant option is not allowed. Thanks regards, Ramu
Re: [HACKERS] Translations in the distributions
Peter Eisentraut [EMAIL PROTECTED] writes: Am Freitag, 9. Januar 2004 15:51 schrieb Tom Lane: Hmm. So the problem would appear if LC_CTYPE is different from the database encoding? Could we fix it by forcing LC_CTYPE to the database encoding during startup? That would resolve quite a few problems, but I don't think there's a way to know what encoding a given LC_CTYPE value will result in. Hmm. Actually it looks like we already do what I had in mind: ReadControlFile(): if (setlocale(LC_CTYPE, ControlFile-lc_ctype) == NULL) ereport(FATAL, ... So the problem really occurs when database_encoding is set to an encoding that is incompatible with the one implied by the initdb-time LC_CTYPE ... which we have no good way to check. Ugh. I have some vague recollection that glibc offers an API extension that allows this to be checked. Is it worth having a solution that catches the problem on glibc only? 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
Re: [HACKERS] Translations in the distributions
Peter Eisentraut [EMAIL PROTECTED] writes: Remember that gettext will automatically recode the strings depending on what it thinks is the display character set, determined via LC_CTYPE (of course, a useless concept for server software). Hmm. So the problem would appear if LC_CTYPE is different from the database encoding? Could we fix it by forcing LC_CTYPE to the database encoding during startup? 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
Re: [HACKERS] with grant option for user groups.
Following statement says that with grant option is not allowed to a user group. I would like to know what the reasons behind not implementing this kind of feature. Consider the following sequence of steps: in database 1: user A grants privilege to group B with grant option user C who is in group B grants privilege to user D in database 2: superuser removes user C from group B -- user D still has the privilege, because superuser doesn't have access to database 1 from his session If you can live with this problem, then you can remove the check from the source code and it should work. ---(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: [HACKERS] with grant option for user groups.
Theoretically same kind of problem should arise even if the privilege is granted to a user also. To be specific I would like know the answers for the following Q's Scenario 1: === User A grants privilege to group B with grant option. User C who is in group B grants privilege to user D If super user removes the user C from the group, then who is the grantee for the user D? And who can revoke revoke the privileges from user D? Scenario 2: === User A grants privilege to group 'B' and 'Z' with grant option. User C who is in group 'B' and 'Z' grants privilege to user D. If user C removed from the group 'B' then who will be the grantee for user 'D'? And who can revoke revoke the privileges from user D? If user C is removed from both the groups then who will be the grantee for the user? And who can revoke revoke the privileges from user D? Thanks Regards, Ramu -Original Message- From: Peter Eisentraut [mailto:[EMAIL PROTECTED] Sent: Friday, January 09, 2004 8:11 PM To: Potuganti Ramu; [EMAIL PROTECTED] Subject: Re: [HACKERS] with grant option for user groups. Following statement says that with grant option is not allowed to a user group. I would like to know what the reasons behind not implementing this kind of feature. Consider the following sequence of steps: in database 1: user A grants privilege to group B with grant option user C who is in group B grants privilege to user D in database 2: superuser removes user C from group B -- user D still has the privilege, because superuser doesn't have access to database 1 from his session If you can live with this problem, then you can remove the check from the source code and it should work. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Translations in the distributions
On Fri, 9 Jan 2004, Tom Lane wrote: on what it thinks is the display character set, determined via LC_CTYPE (of course, a useless concept for server software). Hmm. So the problem would appear if LC_CTYPE is different from the database encoding? Could we fix it by forcing LC_CTYPE to the database encoding during startup? What does database encoding has to do with error messages and the display character set? -- /Dennis Björklund ---(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: [HACKERS] Translations in the distributions
Am Freitag, 9. Januar 2004 15:51 schrieb Tom Lane: Hmm. So the problem would appear if LC_CTYPE is different from the database encoding? Could we fix it by forcing LC_CTYPE to the database encoding during startup? That would resolve quite a few problems, but I don't think there's a way to know what encoding a given LC_CTYPE value will result in. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Translations in the distributions
Am Freitag, 9. Januar 2004 16:28 schrieb Dennis Björklund: What does database encoding has to do with error messages and the display character set? When they are sent over the wire, the messages are converted from server (=database) encoding to client encoding. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] OLE DB driver
Shachar Shemesh wrote: Hi all, After unsuccessfully trying to join the current OLE DB project on gborg, I'm writing my own. So far I don't have anything too fancy (just trying to get over the initial shock of what OLE DB actually is). It currently does the basic infrastructure, but does not yet actually connect to Postgresql. If anyone else has written code, was contemplating writing code, has access to the gborg project, or is otherwise interested, please let me know. I wonder if this could be implemented as a wrapper around libpq. This way, the OLEDB driver would benefit from a proven piece of software. Regards, Andreas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Encoding problems in PostgreSQL with XML data
Rewriting the ?xml? declaration seems like a workable solution, but it would break the transparency of the client/server encoding conversion. Also, some people might dislike that their documents are being changed as they are stored. I presume that the XML type stores the textual representation of the XML rather than a binary (parsed) format? I say we treat XML the same was as we deal with things like float and allow some play with the stored object so long as it's reasonably small and has the same final interpretation. If they wanted non-mutable text, they would not have declared it as a structured format. Just like if they don't want leading 0's removed from numeric input, they don't declare it as numeric but as binary. ---(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: [HACKERS] Encoding problems in PostgreSQL with XML data
Peter Eisentraut wrote: The central problem I have is this: How do we deal with the fact that an XML datum carries its own encoding information? Maybe I am misunderstanding your question, but IMO postgres should be treating xml documents as if they were binary data, unless the server takes on the role of a parser, in which case it should handle unspecified/unknown encodings just like a normal xml parser would (and this does *not* include changing the encoding!). According to me, an XML parser should not change one bit of a document, because that is not a 'parse', but a 'transformation'. Rewriting the ?xml? declaration seems like a workable solution, but it would break the transparency of the client/server encoding conversion. Also, some people might dislike that their documents are being changed as they are stored. Right, your example begs the question: why does the server care what the encoding of the documents is (perhaps indexing)? ZML validation is a standardized operation which the server (or psql, I suppose) can subcontract out to another application. Just a side thought: what if the xml encoding type was built into the domain type itself? create domain xml_utf8 ... Which allows casting, etc. which is more natural than an implicit transformation. Regards, Merlin ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Encoding problems in PostgreSQL with XML data
Perhaps the document should be stored in canonical form. See http://www.w3.org/TR/xml-c14n I think I agree with Rod's opinion elsewhere in this thread. I guess the philosophical question is this: If 2 XML documents with different encodings have the same canonical form, or perhaps produce the same DOM, are they equivalent? Merlin appears to want to say no, and I think I want to say yes. cheers andrew Merlin Moncure wrote: Peter Eisentraut wrote: The central problem I have is this: How do we deal with the fact that an XML datum carries its own encoding information? Maybe I am misunderstanding your question, but IMO postgres should be treating xml documents as if they were binary data, unless the server takes on the role of a parser, in which case it should handle unspecified/unknown encodings just like a normal xml parser would (and this does *not* include changing the encoding!). According to me, an XML parser should not change one bit of a document, because that is not a 'parse', but a 'transformation'. Rewriting the ?xml? declaration seems like a workable solution, but it would break the transparency of the client/server encoding conversion. Also, some people might dislike that their documents are being changed as they are stored. Right, your example begs the question: why does the server care what the encoding of the documents is (perhaps indexing)? ZML validation is a standardized operation which the server (or psql, I suppose) can subcontract out to another application. Just a side thought: what if the xml encoding type was built into the domain type itself? create domain xml_utf8 ... Which allows casting, etc. which is more natural than an implicit transformation. Regards, Merlin ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] OLE DB driver
Andreas Pflug wrote: I wonder if this could be implemented as a wrapper around libpq. This way, the OLEDB driver would benefit from a proven piece of software. Regards, Andreas That's what I'm doing. I'm not sure why other drivers didn't do that as well (maybe there was no native Windows port of libpq at the time?). My reason is actually that I'm not a great postgres hacker, and I would rather rely as little as possible on internal structures and things that are likely to change in the future. Shachar -- Shachar Shemesh Lingnu Open Systems Consulting http://www.lingnu.com/ ---(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: [HACKERS] Translations in the distributions
Tom Lane wrote: So the problem really occurs when database_encoding is set to an encoding that is incompatible with the one implied by the initdb-time LC_CTYPE ... which we have no good way to check. Ugh. I have some vague recollection that glibc offers an API extension that allows this to be checked. Is it worth having a solution that catches the problem on glibc only? The problem is more likely to be that it will be hard to match up the different encoding names. For example, if you set LC_CTYPE=C, then the system encoding is report as $ locale charmap ANSI_X3.4-1968 whereas the closest thing in PostgreSQL would be SQL_ASCII. It might already help if we allowed LC_CTYPE to be attached to a database rather than the entire cluster, and make the user match them up manually. The only drawback would be that indexes on global tables involving upper() or lower() would no longer work reliably. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Encoding problems in PostgreSQL with XML data
Andrew Dunstan wrote: I think I agree with Rod's opinion elsewhere in this thread. I guess the philosophical question is this: If 2 XML documents with different encodings have the same canonical form, or perhaps produce the same DOM, are they equivalent? Merlin appears to want to say no, and I think I want to say yes. Er, yes, except for canonical XML. Canonical XML neatly bypasses all the encoding issues that I can see. Maybe I am still not getting the basic point, but the part I was not quite clear on is why the server would need to parse the document at all, much less change the encoding. Sure, it doesn't necessarily hurt to do it, but why bother? An external parser could handle both the parsing and the validation. Reading Peter's post, he seems to be primarily concerned with an automatic XML validation trigger that comes built in with the XML 'type'. *unless* 1. The server needs to parse the document and get values from the document for indexing/key generation purposes, now the encoding becomes very important (especially considering joins between XML to non XML data types). 2. There are plans to integrate Xpath expressions into queries. 3. The server wants to compose generated XML documents from stored XML/non XML sources, with (substantial) additions to the query language to facilitate this, i.e. a nested data extraction replacement for psql. But, since I'm wishing for things, I may as well ask for a hockey rink in my living room :) Merlin ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Encoding problems in PostgreSQL with XML data
Andrew Dunstan wrote: Perhaps the document should be stored in canonical form. That kills the DTD, the id attributes, thus crippling XPath, and it looks horrible on output. I don't think that can be accepted. Canonical form is useful for comparing documents, but not for operating on them, I think. ---(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: [HACKERS] Translations in the distributions
Peter Eisentraut [EMAIL PROTECTED] writes: It might already help if we allowed LC_CTYPE to be attached to a database rather than the entire cluster, and make the user match them up manually. The only drawback would be that indexes on global tables involving upper() or lower() would no longer work reliably. Make that indexes on global tables involving any text wouldn't work. Everyone has to have the same notion of the sort order, or the index is corrupt from someone's point of view, and soon from everyone's point of view. upper/lower isn't needed to cause a problem. However ... we do not have any global tables with indexed text columns. Only name columns, and name comparisons are presently not locale-aware (they're just strncmp()). I think it wouldn't be unreasonable to legislate that this remain true forevermore, and then it would be safe to allow different DBs to run in different locales. That would be a big step forward, for sure. [ thinks more... ] Actually it's a bigger restriction than that. Imagine that you create some tables with text data in template1, and then index them. The indexes would be corrupt if you cloned template1 and assigned the result a different locale. So to make this work, we'd actually need the following restrictions: * No system table can ever have an index on a text/varchar/char column; only name columns, and name has to remain locale-unaware. * You can't assign a new locale to a cloned database if the source has any text/varchar/char indexes. The simplest implementation restriction I can think of to guarantee point 2 is to allow changing the locale only when cloning template0, not when cloning anything else. Or we could just warn people that they'd better reindex after changing the locale. It does seem like this might be a reasonable path to take. Thoughts? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Encoding problems in PostgreSQL with XML data
Peter Eisentraut wrote: Andrew Dunstan wrote: Perhaps the document should be stored in canonical form. That kills the DTD, the id attributes, thus crippling XPath, and it looks horrible on output. I don't think that can be accepted. Canonical form is useful for comparing documents, but not for operating on them, I think. OK, fair enough. What exactly do we expect the functionality of an xml type to be? Merely a guarantee that it is well-formed? cheers andrew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] Announce: Search PostgreSQL related resources
On Tue, 6 Jan 2004, Rajesh Kumar Mallah wrote: Hi, Could you please tell how the did you mean feature was implemented when the serach term has a typo. it's based on trigrams similarity and words statistics. The search engine is good . Regds mallah. Oleg Bartunov wrote: Hi there, I'm pleased to present pilot version of http://www.pgsql.ru - search system on postgresql related resources. Currently, we have crawled 27 sites, new resources are welcome. It has multi-languages interface (russian, english) but more languages could be added. We plan to add searchable archive of mailing lists (a'la fts.postgresql.org), russian documentation and WIKI for online documentation, tips, etc. We are welcome your feedback and comments. We need design solution, icons. This project is hosted at Sternberg Astronomical Institute, Moscow University and supported by Russian Foundation for Basic Research and Delta-Soft LLC. Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(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 ---(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 Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
