At 07:49 24/11/00 -, Peter Mount wrote:
There's bound to be a better way, but in the NT resource kit there was a
tool you can use to make any .exe a service.
Without modifying the postmaster, this is probably the best solution. An NT
service has to handle and respond to various events
Carlos Jacobs wrote:
Hi:
I have a MS Access database with tables containing TEXT fields.
I need import that info in a postgres 7 table.
How to do it?
If I use copy from, dont work.
I have a perl program which will import this sort of multi-line CSV data
that is not handled by the COPY ...
Hi,
First excuse me for my bad english,
I use postgresql V7.0.2 with linux and I found a stange
result with create table.
CREATE TABLE "UTILISATEURS" (
..
);
Ok no problem, and when i use \\dt under pgsql i see this
name. But when i write select * from UTILISATEURS ,it doesn't
work.
Hi,
I had a problem porting applications from mySQL.
I can't find info on this in the docs... so mailed the list, sorry for
my english.
I create the fileds name with first letter uppercase, I need this way,
because the result set must have the fileds name with the correct case
in PHP.
I
[EMAIL PROTECTED] writes:
Strnage isn't it
No. That's the intended and documented behavior. See the manual, eg,
http://www.postgresql.org/users-lounge/docs/7.0/postgres/syntax525.htm
regards, tom lane
- Original Message -
From: "Dan Wilson" [EMAIL PROTECTED]
To: "pgsql general" [EMAIL PROTECTED]
Sent: Sunday, November 19, 2000 9:33 AM
Subject: DB and Table Permissions
Is there a reason why _any_ user can create a table on a database?
Even if
they do not own or have
Peter Eisentraut [EMAIL PROTECTED] writes:
I have now received positive proof that en_US sort order on RedHat is
broken. For example, it asserts
'/root/' '/root0'
but
'/root/t' '/root0'
I defy you to find anyone in the US who will say that that is a
reasonable definition of string
Tom Lane wrote:
that contains only (or mostly) words like that. But I've got strong
doubts that the average user of a default RedHat installation expects
*all* data to get sorted that way, or that he wants us to honor a
default that he didn't ask for to the extent of disabling LIKE
Lamar Owen [EMAIL PROTECTED] writes:
I am not at all happy about the 'broken' RedHat locale -- the quick and
dirty solution is to remove or rename '/etc/sysconfig/i18n' -- but that
doesn't cure the root issue.
Actually, that suggestion points out that just nailing down LC_COLLATE
at initdb
Possible compromise: let initdb accept en_US, but have it spit out a
warning message:
NOTICE: initializing database with en_US collation order.
If you're not certain that's what you want, then it's probably not what
you want. We recommend you set LC_COLLATE to "C" and re-initdb.
For more
Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
Oh, and to make matters that much worse, on a RedHat system it doesn't
matter if you build with or without --enable-locale -- locale support is
in the libc used, and locale support gets used regardless of what you
select on the
Vadim,
In xlog.c, the declaration of struct ControlFileData says:
/*
* MORE DATA FOLLOWS AT THE END OF THIS STRUCTURE - locations of data
* dirs
*/
Is this comment accurate? I don't see any sign in the code of placing
extra data after the declared structure. If you're
Tom Lane writes:
Possible compromise: let initdb accept en_US, but have it spit out a
warning message:
NOTICE: initializing database with en_US collation order.
If you're not certain that's what you want, then it's probably not what
you want. We recommend you set LC_COLLATE to "C" and
Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
Collation was the same, regardless of the --enable-locale
setting. I got lots of 'bug' reports about the RPM's failing
Hmm. I reviewed that thread and found this comment from you:
: In a nutshell, yes. /etc/sysconfig/i18n on the
At 07:32 PM 11/24/00 -0500, Tom Lane wrote:
Possible compromise: let initdb accept en_US, but have it spit out a
warning message:
NOTICE: initializing database with en_US collation order.
If you're not certain that's what you want, then it's probably not what
you want. We recommend you set
Don Baccus [EMAIL PROTECTED] writes:
Are you SURE you want to use en_US collation? [no]
(ask the question, default to no?)
Yes, a question in initdb is ugly, this whole thing is ugly.
A question in initdb won't fly for RPM installations, since the RPMs
try to do initdb themselves (or am I
Tom Lane wrote:
Don Baccus [EMAIL PROTECTED] writes:
Are you SURE you want to use en_US collation? [no]
(ask the question, default to no?)
Yes, a question in initdb is ugly, this whole thing is ugly.
A question in initdb won't fly for RPM installations, since the RPMs
try to do
Lamar Owen [EMAIL PROTECTED] writes:
A command-line argument to initdb would suffice to override -- maybe a
'--initlocale' parameter??
Hardly need one, when setting LANG or LC_ALL will do just as well.
Now, what sort of default for --initlocale.
I think your complaints about RedHat's
Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
I think your complaints about RedHat's default are right back in your
lap ;-). Do you want to ignore their default, or not?
Yes, I want to ignore their default. This problem is more than just
cosmetic, thanks to the bugs that sparked this
Bruce Momjian writes:
The 7.1 code will the socket location configurable.
Btw., are you still about to change it to the directory rather than the
file? I'd suggest that you change the GUC parameter to
"unix_socket_directory", to be consistent in naming with related
parameters.
Done.
Applied.
* Tom Lane [EMAIL PROTECTED] [001122 22:44]:
Larry Rosenman [EMAIL PROTECTED] writes:
Looking some more, I found some other places that need a space (I
suspect...), so here is an updated patch.
This seems like the wrong way to go about it, because anytime anyone
changes
Applied. :-)
* Larry Rosenman [EMAIL PROTECTED] [001123 01:10]:
* Tom Lane [EMAIL PROTECTED] [001122 22:44]:
Makes sense. Here's a new patch, now the output even looks better:
Nov 23 00:58:04 lerami pg-test[9914]: [2-1] NOTICE: QUERY PLAN:
Nov 23 00:58:04 lerami pg-test[9914]: [2-2]
Andrew Bartlett wrote:
This code in psql/command.c allows *any* system user to place a
predictably named symbolic link in /tmp and use it to alter/destroy
files owned by the user running psql. (tested - postgresql 7.0.2).
All the information a potential attacker would need are available
Someone ought to backpatch to REL_7_0_PATCHES, as it's syslog also
looks bad...
LER
* Bruce Momjian [EMAIL PROTECTED] [001124 22:38]:
Applied. :-)
* Larry Rosenman [EMAIL PROTECTED] [001123 01:10]:
* Tom Lane [EMAIL PROTECTED] [001122 22:44]:
Makes sense. Here's a new patch, now
Someone ought to backpatch to REL_7_0_PATCHES, as it's syslog also
looks bad...
Not sure if we will have a 7.0.4, and I can't see it as a major bug
problem anyway.
LER
* Bruce Momjian [EMAIL PROTECTED] [001124 22:38]:
Applied. :-)
* Larry Rosenman [EMAIL PROTECTED] [001123
Thanks for the pointer. Here is a diff to fix the problem. How does it
look to you?
This code in psql/command.c allows *any* system user to place a
predictably named symbolic link in /tmp and use it to alter/destroy
files owned by the user running psql. (tested - postgresql 7.0.2).
All
Max Fonin [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
I guess the problem is that PL/pgSQL doesn't handle opaque type correctly.
No it doesn't, which is not surprising considering that opaque isn't
really a type at all. The error message could be improved though :-(
Well,
On Thu, 23 Nov 2000 11:13:28 -0500
Tom Lane [EMAIL PROTECTED] wrote:
Max Fonin [EMAIL PROTECTED] writes:
I guess the problem is that PL/pgSQL doesn't handle opaque type correctly.
No it doesn't, which is not surprising considering that opaque isn't
really a type at all. The error message
28 matches
Mail list logo
