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, b
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
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
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"
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 thi
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 o
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
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
> Rewriting the 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 representat
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 ye
This is not directly related to current development, but it is something
that might need a low-level solution. I've been thinking for some time
about how to enchance the current "XML support" (e.g., contrib/xml).
The central problem I have is this: How do we deal with the fact that
an XML dat
Potuganti Ramu wrote:
> 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 fro
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.
---(e
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
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
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
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
> 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 i
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 diff
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
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
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
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
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 f
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
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=# com
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:
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 catalogu
=?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
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 f
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 , because they
>>>reflect
>>>my in
31 matches
Mail list logo
