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 (STAR
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 COP
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. i
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 woul
<[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
... and I am not going to allow 7.1 to go out without a fix for this
class of problems. I'm fed up ;-)
As near as I can tell from the setlocale() man page, the only locale
categories that are really hazardous for us are LC_COLLATE and LC_CTYPE;
the other categories like LC_MONETARY affect only I
Tom Lane writes:
> I propose, therefore, that in an --enable-locale installation, initdb
> should save its values for LC_COLLATE and LC_CTYPE in pg_control, and
> backend startup should restore these settings from pg_control.
Note that when these are unset there might still be a "catch-all" loca
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> I propose, therefore, that in an --enable-locale installation, initdb
>> should save its values for LC_COLLATE and LC_CTYPE in pg_control, and
>> backend startup should restore these settings from pg_control.
> Note that when thes
Tom Lane writes:
> >> Also, since "LC_COLLATE=en_US" seems to misbehave rather spectacularly
> >> on recent RedHat releases, I propose that initdb change "en_US" to "C"
> >> if it finds that setting. (Are there any platforms where there are
> >> non-bogus differences between the two?)
>
> > The
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 definitio
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
> opti
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 configure line :-(.
I
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 initd
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 informa
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 t
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 plann
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
> regression, giving an unexpected sort order (see the archives -- the
> best model thread's start post is:
> http://www.postgresql.org
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" a
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Possible compromise: let initdb accept en_US, but have it spit out a
>> warning message:
> I certainly don't like treating en_US specially, when in fact all locales
> are affected by this.
Well, my thought was that another locale
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
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
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 t
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'
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
> 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.
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
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[9
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 availa
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 via a
simple 'ps'.
It might (un
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 ne
> 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 PROTECT
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).
>
> A
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 thou
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 erro
I'm building a new geo type and would like to index it. I have heard about
RTREE and boundary box but I'm clueless for the moment about the
implementation
I have tried to look into PG source code to find the location where the
indexing is done of current line object is done, but couldn't pin
37 matches
Mail list logo
