Joshua D. Drake wrote:
Hello,
Version 7.5 is as close to a major release as I have seen in the almost
9 years I have been using PostgreSQL.
This release brings about a lot of "enterprise" features that have been
holding back PostgreSQL in a big way for
for a long time.
All of my serious customer
On Sun, Aug 01, 2004 at 12:20:59PM +0800, Christopher Kings-Lynne wrote:
> >>This is more features worth mentioning than we've ever had in a single
> >>release before -- and if you consider several add-ons which have been
> >>implemented/improved at the same time (Slony, PL/Java, etc.) it's even
I have added descriptions to many TODO items.
I need help with all the items marked with question marks. Please post
your comment and CVS committers are welcome to modify it directly.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610)
The big problem is that it didn't add an extra \ in the cases I
mentioned. There were other strings that looked like:
"XXX\XX"
where X is a high-bit character. Notice there is only one backslash.
---
Zhenbang Wei
Some characters in Big5 encoding has a / on
second byte and I think poEdit will add another / for me.
Now I think I should use UTF-8 instead of Big5.
I will send new files in minutes. Sorry for causing problems.
On Sun, 1 Aug 2004 00:48:21 -0400 (EDT), Bruce Momjian
<[EMAIL PROTECTED]> wrote:
>
Christopher Kings-Lynne wrote:
> >>This is more features worth mentioning than we've ever had in a single release
> >>before -- and if you consider several add-ons which have been
> >>implemented/improved at the same time (Slony, PL/Java, etc.) it's even more
> >>momentous. If this isn't 8.0,
Ah, just the person I was looking for. I see in the initdb po file you
sent that the use of backslashes in the message string is causing some
of us problems.
What are the rules for backslashes in translation files? I particularly
had problems with lines 199, 260, and 461 in the initdb po file b
This is more features worth mentioning than we've ever had in a single release
before -- and if you consider several add-ons which have been
implemented/improved at the same time (Slony, PL/Java, etc.) it's even more
momentous. If this isn't 8.0, then what will be?
I tend to agree, and was
So, as far as you're concerned, there will never ever be an 8.0.
Eventually we'll do the Sun switcheroo and follow release 7.12 by 13.0.
How about 7.5i :)
Chris
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index sc
On 07/31/04:30/6, Tom Lane wrote:
> Is there any actual functional usefulness to that, or is it just to
> avoid having to reorder existing code to fit into the try/catch paradigm?
Both, I imagine. In the case of the former, it *may be* useful for someone to
create their own paradigm, which seems li
Hello,
Version 7.5 is as close to a major release as I have seen in the almost
9 years I have been using PostgreSQL.
This release brings about a lot of "enterprise" features that have been
holding back PostgreSQL in a big way for
for a long time.
All of my serious customers; potential, existi
Bruce Momjian <[EMAIL PROTECTED]> writes:
> You are asking if a funciton itself might want to set query cancel and
> catch the cancel and do something else?
Exactly. There's a proof-of-concept test at the bottom of
regress/sql/plpgsql.sql, wherein a function gets control back
from a query that wo
I am fine with either numbering, but I think the 8.0 might make more
sense.
---
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Alvaro Herrera wrote:
> >> What was the rule for increasing the first number
You are asking if a funciton itself might want to set query cancel and
catch the cancel and do something else? For 7.5 I would be happy just
canceling the entire thing.
---
Tom Lane wrote:
> Now that it is possible for plpg
James William Pye <[EMAIL PROTECTED]> writes:
> On 07/28/04:30/3, Tom Lane wrote:
>> Does anyone have a problem with this macro syntax? The try/catch names
>> are stolen from Java, so I'm figuring they won't terribly surprise any
>> modern programmer, but I'm open to different names if anyone has
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> What was the rule for increasing the first number after just before
>> 7.0?
> That was just to avoid having to release a 6.6.6, which Jan had clearly
> been working towards. :-)
AFAIR, we had informally been referring to tha
On 07/28/04:30/3, Tom Lane wrote:
> In service of the refactoring of error handling that I was talking about
> a few days ago, I'm finding that there are several places that really
> ought to catch longjmps and clean up after themselves, instead of
> expecting that whatever mess they've made will b
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Think about what "open source" means. It doesn't mean that we give our
> users binary blobs compiled on some guy's machine, because it's too
> inconvenient to obtain the build tools. If it's too inconvenient to
> obtain build tools, you use a bina
Josh Berkus <[EMAIL PROTECTED]> writes:
> Even if Savepoints don't make it, we'll still have:
Savepoints are in, as is exception-trapping in functions (at least
plpgsql, the other PLs are on their own :-().
Some other major improvements you didn't mention:
Cross-datatype comparisons are indexabl
Alvaro Herrera wrote:
> What was the rule for increasing the first number after just before
> 7.0?
That was just to avoid having to release a 6.6.6, which Jan had clearly
been working towards. :-)
Seriously, major version jumps correspond to epoch-like changes, like
when the code moved out of B
Josh Berkus wrote:
> So, as far as you're concerned, there will never ever be an 8.0.
Eventually we'll do the Sun switcheroo and follow release 7.12 by 13.0.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TI
On Sun, Aug 01, 2004 at 12:02:47AM +0200, Peter Eisentraut wrote:
> Josh Berkus wrote:
> > > We've also never had a single release before that had its version
> > > number jump determined by the number of features.
> >
> > That's a non-argument, Peter; we don't have any clear criteria for
> > versi
>> The discussion back when it was decided weighted things back and
>> forth. The main thing is that we'd include an extra build dependency
>> for win32, which would be the Microsoft toolkit, several hundred Mb
>> to download just to build a 32 byte file.
>
>Think about what "open source" means. I
Peter,
> Oh yes, we have very clear criteria: For patch releases, we increase the
> third number, for feature releases we increase the second number and
> set the third number to zero. Clear enough?
So, as far as you're concerned, there will never ever be an 8.0.
--
Josh Berkus
Aglio Database
Magnus Hagander wrote:
> The discussion back when it was decided weighted things back and
> forth. The main thing is that we'd include an extra build dependency
> for win32, which would be the Microsoft toolkit, several hundred Mb
> to download just to build a 32 byte file.
Think about what "open
Josh Berkus wrote:
> > We've also never had a single release before that had its version
> > number jump determined by the number of features.
>
> That's a non-argument, Peter; we don't have any clear criteria for
> version number jump.
Oh yes, we have very clear criteria: For patch releases, we i
>If pgevent is a DLL, why is it in src/bin?
>
>We cannot have binary files like MSG1.bin in our source tree, no
>matter how convenient it is. The distributors are going to
>kill us for
>that. Please find another way.
The discussion back when it was decided weighted things back and forth.
Peter,
> We've also never had a single release before that had its version number
> jump determined by the number of features.
That's a non-argument, Peter; we don't have any clear criteria for version
number jump.
--
Josh Berkus
Aglio Database Solutions
San Francisco
If pgevent is a DLL, why is it in src/bin?
We cannot have binary files like MSG1.bin in our source tree, no
matter how convenient it is. The distributors are going to kill us for
that. Please find another way.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---
Josh Berkus wrote:
> This is more features worth mentioning than we've ever had in a
> single release before
We've also never had a single release before that had its version number
jump determined by the number of features.
> I talked to a few of our people at OSCON who agreed with me. We'd
>
Folks,
Well, we're past feature freeze and with one reservation we know what's in the
next version. After talking to several people at OSCON, I want to revive a
discussion: whether this is 7.5 or 8.0. We tabled that discussion in April
pending a feature list.
Even if Savepoints don't make
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> Ok. So the problem is that functions from libpgport aren't included in
> postgres.def, and thus not in libpostgres.a. It seems that can be fixed
> with the following patch, which is probably a whole lot close to being
> right than what I did before:
>> pg_strcasecmp is *not* included in libpostgres.a. It is in
>> port/libpgport.a, though. (It's also in postgres.exe, but we
>don't link
>> against that..)
>
>What do you mean we don't link against that? There must be hundreds of
>functions in the main backend that plpgsql.dll needs to call. H
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> pg_strcasecmp is *not* included in libpostgres.a. It is in
> port/libpgport.a, though. (It's also in postgres.exe, but we don't link
> against that..)
What do you mean we don't link against that? There must be hundreds of
functions in the main back
Hi Tom,
I have sent you and the list the HTML page from the oracle tech network
describing all of this. However, it seems to have disappeared in to the
void since you don't seem to have received it and it hasn't hit the list
yet.
You can get a free login to access all the oracle docs and manua
>> With the latest commits, plpgsql no longer compiles on
>win32, because of
>> a link failure to pg_strcasecmp().
>
>That doesn't make any sense. It should resolve it as a function in the
>backend. Why isn't that happening?
Dunno...
Build output without my fix is:
dlltool --export-all --outp
Hi all,
I have another PITR question on my mind:
As I see it, PITR has 2 functions:
1 is to recover a disaster like a disk crash. Change the disk, restore
PGDATA and play the logs back that'fine.
2 Junior DBA (or customer) says "ch..; I droped the wrong table..."
In that case, restoring PGDATA
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> With the latest commits, plpgsql no longer compiles on win32, because of
> a link failure to pg_strcasecmp().
That doesn't make any sense. It should resolve it as a function in the
backend. Why isn't that happening?
regards
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Can anyone check how well the syntax of plpgsql EXCEPTION, as described
>> at
>> http://developer.postgresql.org/docs/postgres/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING
>> agrees with what Oracle does?
> It appears you ca
With the latest commits, plpgsql no longer compiles on win32, because of
a link failure to pg_strcasecmp().
I fixed this locally by adding "-lpgport" to SHLIB_LINK in the makefile
in pl/plpgsql/src, but I'm not sure if that is the correct long-term
fix?
//Magnus
---(end
Hi Peter,
> > > > I am using an OpenBSD 3.5. OpenBSD doesn't have 'CODESET' symbol.
> > > > How can we fix it?
> > >
> > > Put #ifdef CODESET around the offending code.
> >
> > OK. Another try.
>
> What does
>
> nl_langinfo(NULL)
>
> return? Probably not a valid codepage.
>
No. Just "". S
Hello,
From I can tell from Oracle pl/SQL programming page 130 ;) it is
identical. However Oracle does have thinkgs like EXCEPTION_INIT.
Here are the name of the Oracle predefined exceptions:
CURSOR_ALREADY_OPEN
DUP_VAL_ON_INDEX
INVALID_CURSOR
INVALID_NUMBER
LOGIN_DENIED
NO_DATA_FOUND
NOT_LOGGED_
Tom Lane wrote:
Can anyone check how well the syntax of plpgsql EXCEPTION, as described
at
http://developer.postgresql.org/docs/postgres/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING
agrees with what Oracle does? I did some googling but couldn't find
anything that seemed authoritative.
Euler Taveira de Oliveira wrote:
> > > I am using an OpenBSD 3.5. OpenBSD doesn't have 'CODESET' symbol.
> > > How can we fix it?
> >
> > Put #ifdef CODESET around the offending code.
>
> OK. Another try.
What does
nl_langinfo(NULL)
return? Probably not a valid codepage.
--
Peter Eisentra
Can anyone check how well the syntax of plpgsql EXCEPTION, as described
at
http://developer.postgresql.org/docs/postgres/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING
agrees with what Oracle does? I did some googling but couldn't find
anything that seemed authoritative. I'm wondering in
Hi Peter,
> > I am using an OpenBSD 3.5. OpenBSD doesn't have 'CODESET' symbol.
> > How can we fix it?
>
> Put #ifdef CODESET around the offending code.
>
OK. Another try.
--
Euler Taveira de Oliveira
euler (at) ufgnet.ufg.br
Desenvolvedor Web e Administrador de Sistemas
UFGNet - Universidade
Tom Lane wrote:
Euler Taveira de Oliveira <[EMAIL PROTECTED]> writes:
I am using an OpenBSD 3.5. OpenBSD doesn't have 'CODESET' symbol.
How can we fix it?
1) just define it on configure.in when we don't have it. Like this:
You've got to be kidding. That will cause get_encoding_fro
Now that it is possible for plpgsql functions (and, no doubt, soon
others) to trap errors, I think we need a little bit of discussion
about what kind of restrictions should be put on trapping the
QUERY_CANCELED error. If we treat QUERY_CANCELED as an absolutely
ordinary error, it would be fairly e
Euler Taveira de Oliveira <[EMAIL PROTECTED]> writes:
> I am using an OpenBSD 3.5. OpenBSD doesn't have 'CODESET' symbol.
> How can we fix it?
> 1) just define it on configure.in when we don't have it. Like this:
You've got to be kidding. That will cause get_encoding_from_locale to
return some r
Euler Taveira de Oliveira wrote:
> I am using an OpenBSD 3.5. OpenBSD doesn't have 'CODESET' symbol.
> How can we fix it?
Put #ifdef CODESET around the offending code.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)
Hi,
I am seeing the following compile failure in currrent CVS.
gmake[4]: Leaving directory `/dados/pgsql/cvs/pgsql/src/port'
gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations
-DFRONTEND -I../../../src/interfaces/libpq -I../../../src/include -I/usr/local/include
-
Zoltan Bartko wrote:
> attached you may find the slovak (sk) translation of the psql message
> strings.
Installed.
> I wanted to check out the newest ones (my version is from jul.16) but
> I was told by my browser that no such file existed
> (http://developer.postgresql.org/~petere/nlsstatus/po-c
Dear hackers,
attached you may find the slovak (sk) translation of the psql message strings.
I wanted to check out the newest ones (my version is from jul.16) but I was
told by my browser that no such file existed
(http://developer.postgresql.org/~petere/nlsstatus/po-current/psql.pot), so
mayb
53 matches
Mail list logo
