Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> Hi, I heard something like "untrusted PL/tcl". Does anybody know what
> the status of that is?
AFAIK it's up and working in 7.1, though I haven't tried it myself. See
http://www.postgresql.org/devel-corner/docs/postgres/pltcl.htm
[ Charset ISO-8859-1 unsupported, converting... ]
> > As you can see from the current open items list, there isn't much left
> > to do for the 7.1 release. I am going to suggest we remove the LAZY
> > VACUUM option at this point. I know Tom Lane posted an item about the
>
> Well, leaving for va
from Feb 15 till Mar 6...
I'll not be able to read mail lists, so
in the event of needs please use
[EMAIL PROTECTED] address.
Regards!
Vadim
> > O, your system reached max transaction ID -:(
>
> That's two reports now of people who have managed to wrap around the XID
> counter. It doesn't seem that hard to do in a heavily used database.
>
> Does anyone want to take more seriously the stopgap solution I proposed
> for this proble
> As you can see from the current open items list, there isn't much left
> to do for the 7.1 release. I am going to suggest we remove the LAZY
> VACUUM option at this point. I know Tom Lane posted an item about the
Well, leaving for vacation tomorrow I have to agree -:(
LAZY patch will be avail
Hi, I heard something like "untrusted PL/tcl". Does anybody know what
the status of that is?
--
Tatsuo Ishii
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>> Are these encodings all guaranteed to have the same collation order as
>> SQL_ASCII?
> Yes & no.
Um, I'm confused ...
>> If not, we have the same index corruption issues as for LOCALE.
> If the backend is configued with LOCALE enabled and the databa
> We now have defenses against running a non-LOCALE-enabled backend in a
> database that was created in non-C locale. Shouldn't we likewise
> prevent a non-MULTIBYTE-enabled backend from running in a database with
> a multibyte encoding that's not SQL_ASCII? Or am I missing a reason why
> that i
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane writes:
> >> We now have defenses against running a non-LOCALE-enabled backend in a
> >> database that was created in non-C locale. Shouldn't we likewise
> >> prevent a non-MULTIBYTE-enabled backend from running in a database with
> >> a
> Far as I know, we were OK on that before.
We weren't last time I tested (there was a thread on this a while ago),
but...
> This is per spec, no?
... it sure is. Looks great!
- Thomas
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> We now have defenses against running a non-LOCALE-enabled backend in a
>> database that was created in non-C locale. Shouldn't we likewise
>> prevent a non-MULTIBYTE-enabled backend from running in a database with
>> a multibyte e
> > Actually, I have something from Oliver Elphick called pg_controldata:
>
> Could you send it to me so that I can find out how he gets the
> LC_COLLATE
> and LC_CTYPE from backend (assuming it tells backend locale not cients)
> ?
>
> > $ pg_controldata
> > Log file id:
Tom Lane writes:
> We now have defenses against running a non-LOCALE-enabled backend in a
> database that was created in non-C locale. Shouldn't we likewise
> prevent a non-MULTIBYTE-enabled backend from running in a database with
> a multibyte encoding that's not SQL_ASCII? Or am I missing a r
Bruce Momjian wrote:
>
> > Bruce Momjian wrote:
> >
> >
> > > P O S T G R E S Q L
> > >
> > > 7 . 1 O P E NI T E M S
> > >
> > > Current at ftp://candle.pha.pa.us/pub/postgresql/open_items.
> >
> > Any possibility of putting my getlocale into contrib ?
> >
> > I agree that it should in fact
> Bruce Momjian wrote:
>
>
> > P O S T G R E S Q L
> >
> > 7 . 1 O P E NI T E M S
> >
> > Current at ftp://candle.pha.pa.us/pub/postgresql/open_items.
>
> Any possibility of putting my getlocale into contrib ?
>
> I agree that it should in fact be in the pg_locale.c but that would be a
We now have defenses against running a non-LOCALE-enabled backend in a
database that was created in non-C locale. Shouldn't we likewise
prevent a non-MULTIBYTE-enabled backend from running in a database with
a multibyte encoding that's not SQL_ASCII? Or am I missing a reason why
that is safe?
I
Bruce Momjian wrote:
> P O S T G R E S Q L
>
> 7 . 1 O P E NI T E M S
>
> Current at ftp://candle.pha.pa.us/pub/postgresql/open_items.
Any possibility of putting my getlocale into contrib ?
I agree that it should in fact be in the pg_locale.c but that would be a
feature and we don't add
Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> ...join visibility issue...
> I'm not sure if the "table shape for natural joins issue" has been
> formalized, but afaik it isn't covered in the scoping patch. Tom?
Far as I know, we were OK on that before.
test=# create table a(f1 int, f2 int);
CRE
Bruce Momjian writes:
> > Bruce Momjian writes:
> >
> > > New PL/pgSQL GET DIAGNOSTICS statement for SPI value access (Jan)
> >
> > If someone can show me an example of how it operates I can write up
> > something.
>
> I found:
>
> > Quoting a recent message by Jan Wieck <[EMAIL PROTECTED]>:
>
> ...join visibility issue...
I'm not sure if the "table shape for natural joins issue" has been
formalized, but afaik it isn't covered in the scoping patch. Tom?
- Thomas
> On Wed, Feb 14, 2001 at 07:43:25PM +0100, Peter Eisentraut wrote:
> > Seems like something that should be done in a separate wrapper program.
> > Littering the backend with vast sections of platform-specific code that
> > provides optional functional is probably not going to fly, if I can assess
On Wed, Feb 14, 2001 at 07:43:25PM +0100, Peter Eisentraut wrote:
> Seems like something that should be done in a separate wrapper program.
> Littering the backend with vast sections of platform-specific code that
> provides optional functional is probably not going to fly, if I can assess
> this
Fred Yankowski writes:
> Jason Tishler and I are planning to create a patch to allow PostgreSQL
> to run directly as an NT service. I've submitted a similar patch
> which may well be incorporated into the next release of Cygipc, and
> we've got a plan for doing the same for PostgreSQL: see
> ht
Fred Yankowski <[EMAIL PROTECTED]> writes:
> Getting to my question: Is it possible to create a CVS branch of the
> HEAD (tip) of the PostgreSQL CVS for us to use in this work?
It seems unlikely that this work is large enough to justify a branch.
Why don't you just work together and submit a pat
> Bruce Momjian writes:
>
> > New PL/pgSQL GET DIAGNOSTICS statement for SPI value access (Jan)
>
> If someone can show me an example of how it operates I can write up
> something.
I found:
> Quoting a recent message by Jan Wieck <[EMAIL PROTECTED]>:
> :Do a
> :
> :GET DIAGNOSTICS
> Tom Lane writes:
>
> > Thomas Lockhart <[EMAIL PROTECTED]> writes:
> > > Also, could the "-F" option be disabled now that WAL is enabled? Or is
> > > there still some reason to encourage/allow folks to use it?
> >
> > I was the one who put it back in after Vadim turned it off ;-) ... and
> > I'
Jason Tishler and I are planning to create a patch to allow PostgreSQL
to run directly as an NT service. I've submitted a similar patch
which may well be incorporated into the next release of Cygipc, and
we've got a plan for doing the same for PostgreSQL: see
http://ontosys.com/phiki/PostgresqlN
Tom Lane writes:
> Thomas Lockhart <[EMAIL PROTECTED]> writes:
> > Also, could the "-F" option be disabled now that WAL is enabled? Or is
> > there still some reason to encourage/allow folks to use it?
>
> I was the one who put it back in after Vadim turned it off ;-) ... and
> I'll object to any
Bruce Momjian writes:
> New PL/pgSQL GET DIAGNOSTICS statement for SPI value access (Jan)
If someone can show me an example of how it operates I can write up
something.
> Improve PL/PgSQL documentation (?)
I agree with the "(?)"... Certainly a bit late to start an "improvement"
project.
> St
As you can see from the current open items list, there isn't much left
to do for the 7.1 release. I am going to suggest we remove the LAZY
VACUUM option at this point. I know Tom Lane posted an item about the
join visibility issue, so hopefully this can be resolved soon. Not sure
what to do abo
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> Sent: 14 February 2001 06:20
> To: PostgreSQL-development
> Cc: PostgreSQL odbc list
> Subject: [ODBC] ODBC <6.4 protocol
>
>
> I have backed out the changes to ODBC that removed compatibility with
> <6.4 servers,
> Tatsuo, what is LC_ALL (or the other locale envvars) set to when you run
> the program? The man page for setlocale() on my machine documents that
> the main() starts in C or POSIX locale mode by default. The call to
> setlocale(LC_ALL, "") reads the envvars and sets the locale
> accordingly.
> > It removes the need to disable fsync to get best performance!
>
> -F performance is still better, only the difference is not so big as before.
Well, when "checkpoint seek in logs" will be implemented difference
will be the same - lost consistency.
> > Since there is a fundamental recovery
> It removes the need to disable fsync to get best performance!
-F performance is still better, only the difference is not so big as before.
> Since there is a fundamental recovery problem if the WAL file
> disappears, then perhaps we should have a workaround which can ignore
> the requirement
Dave Page wrote:
>
> > -Original Message-
> > From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> >
> >
> > I have backed out the changes to ODBC that removed compatibility with
> > <6.4 servers, so the 7.1 ODBC code still supports the older servers.
> > I have changed the dialog box from "6.
35 matches
Mail list logo
