The applied patch fixes libpgport backend linking on Win32. The
solution was to create palloc/pstrdup stubs in the backend and call them
from dirmod.c. Seems the DLLIMPORT modifier on CurrentMemoryContext
means it can't also be referenced in pgport.
This also fixes a broken pg_dumpall implementa
Nope, you need Makefile 1.15. Must be a lag.
---
[EMAIL PROTECTED] wrote:
> Hmmm...updated and tried to rebuild - I get the same error!
>
> It looks like I have the latest src/timezone/Makefile (1.14)
>
> The only thing I
Hmmm...updated and tried to rebuild - I get the same error!
It looks like I have the latest src/timezone/Makefile (1.14)
The only thing I am doing that is a bit different perhaps is :
- on Freebsd performing cvs update -d -P
- followed by ./configure;make dist
- copy the archive to win2000 and
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> OK, I can do this, but I don't think I'll have time for the first beta.
No problem.
> ps. Did you back out the moving of owner to commands as well?
No, just the composite-type thing.
regards, tom lane
---
I just committed the final fix for zic and Claudio has compiled it so
please grab cvs head and give it a try.
---
[EMAIL PROTECTED] wrote:
> Unfortunately I am still seeing the same error - I can "fix" it by with this:
>
>
Unfortunately I am still seeing the same error - I can "fix" it by with this:
*** dirmod.c.orig Sun Aug 8 17:14:48 2004
--- dirmod.cSun Aug 8 17:14:59 2004
***
*** 15,20
--- 15,21
*-
*/
$ pg_dump regression >zzz.out
pg_dump: SQL command failed
pg_dump: Error message from server: ERROR: "complex" is a composite type
pg_dump: The command was: COPY public.complex (r, i) TO stdout;
$
That could be fixed by just checking the relkind when dumping table
data, but hey.
I suspect it had
OK, I have just applied a patch to src/timezone/Makefile which will fix
this by compiling dirmod.c specially like we do in other Makefiles.
Patch attached.
---
[EMAIL PROTECTED] wrote:
> I get a build failure (win 2000 pro)
I get a build failure (win 2000 pro):
gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations
zic.o ialloc.o scheck.o localtime.o -L../../src/port -lpgport -lwsock32 -lm
-lws2_32 -o zic.exe
../../src/port/libpgport.a(dirmod.o)(.text+0xc6):dirmod.c: undefined reference
to
Here is fix for Win32 pg_dumpall that Claudio helped with.
Attached and applied.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.
> Well, this is still working at the wrong level. The code
> that's in pg_verifymbstr is mainly intended to enforce the
> *system wide* assumption that multibyte characters must have
> the high bit set in every byte. (We do not support encodings
> without this property in the backend, because
Tatsuo Ishii wrote:
Tom Lane wrote:
If I understood what I was reading, this would take several things:
* Remove the "special UTF-8 check" in pg_verifymbstr;
* Extend pg_utf2wchar_with_len and pg_utf_mblen to handle the 4-byte case;
* Set maxmblen to 4 in the pg_wchar_table[] entry for UTF-8.
Are
"John Hansen" <[EMAIL PROTECTED]> writes:
> Ahh, but that's not the case. You cannot just delete the check, since
> not all combinations of bytes are valid UTF8. UTF bytes FE & FF never
> appear in a byte sequence for instance.
Well, this is still working at the wrong level. The code that's in
pg
> Tom Lane wrote:
>
> > If I understood what I was reading, this would take several things:
> > * Remove the "special UTF-8 check" in pg_verifymbstr;
> > * Extend pg_utf2wchar_with_len and pg_utf_mblen to handle the 4-byte case;
> > * Set maxmblen to 4 in the pg_wchar_table[] entry for UTF-8.
> >
David Fetter <[EMAIL PROTECTED]> writes:
> This adds a caveat to the inheritance part of the tutorial.
I have a problem with putting this sort of thing in the tutorial.
How about we move the workaround example to chapter 5.5, instead?
regards, tom lane
---
Yes, I just noticed this myself.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
--
This has been saved for the 8.1 release:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
---
Roger Leigh wrote:
-- Start of PGP signed section.
> Hello,
>
> Following the commit of my psql latex format fixes, I've
Patch applied. Thanks.
---
David Fetter wrote:
> Folks,
>
> This patch adds SQL2003 to the set of standards with which PostgreSQL
> is attempting to comply.
>
> Cheers,
> D
> --
> David Fetter [EMAIL PROTECTED] http://f
Patch applied. Thanks.
---
David Fetter wrote:
> Folks,
>
> This adds a caveat to the inheritance part of the tutorial.
>
> Cheers,
> D
> --
> David Fetter [EMAIL PROTECTED] http://fetter.org/
> phone: +1 510 893 6100
Patch applied. Thanks.
---
David Fetter wrote:
> Kind people,
>
> This patch adds an example to the CREATE DOMAIN docs.
>
> Cheers,
> D
> --
> David Fetter [EMAIL PROTECTED] http://fetter.org/
> phone: +1 510 893 6100
Patch applied. Thanks.
---
Gavin Sherry wrote:
> Included is an example of using savepoints in a non-trivial example.
>
> Giving examples in the SQL command reference is hard because we don't have
> conditionals at the SQ
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
I noticed you test for SYMINK instead of HAVE_SYMLINK. I will check it
more lat
OK, got them all. Thanks. Patch attached.
Would someone retest on Win32?
---
Andreas Pflug wrote:
> Bruce Momjian wrote:
> > OK, applied. I moved the funciton into port/dirmod.c and cleaned up the
> > interface for Win32
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> It's nice, but currently there are a lot of ways in which psql is broken
> regarding older server versions. We should be caring about all of them
> (ideal), or about none (the current situation).
> There have been proposals in the past about making tha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> It's nice, but currently there are a lot of ways in which psql is
> broken regarding older server versions. We should be caring about
> all of them (ideal), or about none (the current situation).
>
> There have been proposals in the past about m
Oliver Jowett <[EMAIL PROTECTED]> writes:
> Does this change what client_encoding = UNICODE might produce? The JDBC
> driver will need some tweaking to handle this -- Java uses UTF-16
> internally and I think some supplementary character (?) scheme for
> values above 0x as of JDK 1.5.
You'r
Tom Lane wrote:
If I understood what I was reading, this would take several things:
* Remove the "special UTF-8 check" in pg_verifymbstr;
* Extend pg_utf2wchar_with_len and pg_utf_mblen to handle the 4-byte case;
* Set maxmblen to 4 in the pg_wchar_table[] entry for UTF-8.
Are there any other place
Joe Conway wrote:
> Bruce Momjian wrote:
> > May I have a context diff please, diff -c?
> >
>
> As this is new functionality, I presume it will be held for 8.1,
> correct? In any case, you can put my name on it for review.
Right. OK.
--
Bruce Momjian| http://candle
> -Original Message-
> From: Oliver Elphick [mailto:[EMAIL PROTECTED]
> Sent: Sunday, August 08, 2004 7:43 AM
> To: Tom Lane
> Cc: John Hansen; Hackers; Patches
> Subject: Re: [HACKERS] UNICODE characters above 0x1
>
> On Sat, 2004-08-07 at 07:10, Tom Lane wrote:
> > Oliver Elphick <[
It's nice, but currently there are a lot of ways in which psql is broken
regarding older server versions. We should be caring about all of them
(ideal), or about none (the current situation).
There have been proposals in the past about making that happen. You
could investigate that (please do --
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Sunday, August 08, 2004 2:43 AM
> To: Dennis Bjorklund
> Cc: Tatsuo Ishii; John Hansen; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: [PATCHES] [HACKERS] UNICODE characters above 0x1
>
> Dennis Bjorklund
Bruce Momjian wrote:
May I have a context diff please, diff -c?
As this is new functionality, I presume it will be held for 8.1,
correct? In any case, you can put my name on it for review.
Joe
---(end of broadcast)---
TIP 1: subscribe and unsubscrib
Bruce Momjian wrote:
OK, applied. I moved the funciton into port/dirmod.c and cleaned up the
interface for Win32.
Would someone test this on Win32 in case I broke something?
Yes, something's broken, see patch.
Second, HAVE_SYMLINK must be defined somewhere (configure?).
Third, a junction is a dir
Hello Peter,
This is a quick update for most files with fuzzy
and new translations and some fixed messages.
These are not 100% complete compared to the current CVS,
but I started these some time ago and need them to be
applied to easily grab the updated versions from your
page and fix the rest.
P
Index: describe.c
===
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/describe.c,v
retrieving revision 1.103
diff -c -r1.103 describe.c
*** describe.c 15 Jul 2004 03:56:06 - 1.103
--- describe.c 7 Aug 2004 22:15:03 -0
May I have a context diff please, diff -c?
---
Koju Iijima wrote:
> Hi !
>
> I would like to contribute a patch to the PostgreSQL.
>
> The patch is for the one of TODO items:
>
> *ARRAYS - Allow MIN()/MAX() on arrays
>
>
OK, applied. I moved the funciton into port/dirmod.c and cleaned up the
interface for Win32.
Would someone test this on Win32 in case I broke something? Patch
attached.
---
Andreas Pflug wrote:
> The attached patch implem
On Sat, 2004-08-07 at 07:10, Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> writes:
> > glibc provides various routines (mb...) for handling Unicode. How many
> > of our supported platforms don't have these?
>
> Every one that doesn't use glibc. Don't bother proposing a glibc-only
> soluti
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> On Sat, 7 Aug 2004, Tatsuo Ishii wrote:
>> Anyway my point is if current specification of Unicode only allows
>> 24-bit range, why we need to allow usage against the specification?
> Is there a specific reason you want to restrict it to 24 bits?
I se
> -Original Message-
> From: Dennis Bjorklund [mailto:[EMAIL PROTECTED]
> Sent: Saturday, August 07, 2004 11:23 PM
> To: John Hansen
> Cc: Takehiko Abe; [EMAIL PROTECTED]
> Subject: RE: [PATCHES] [HACKERS] UNICODE characters above 0x1
>
> On Sat, 7 Aug 2004, John Hansen wrote:
>
> >
Yea,. I know
10 - 10 : 2 separate planes iirc
... John
-Original Message-
From: Dennis Bjorklund [mailto:[EMAIL PROTECTED]
Sent: Saturday, August 07, 2004 9:06 PM
To: John Hansen
Cc: Tatsuo Ishii; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: [PATCHES
On Sat, 7 Aug 2004, Tatsuo Ishii wrote:
> More seriously, Unicode is filled with tons of confusion and
> inconsistency IMO. Remember that once Unicode adovocates said that the
> merit of Unicode was it only requires 16-bit width. Now they say they
> need surrogate pairs and 32-bit width chars...
>
Well, maybe we'd be better off, compiling a list of (in?)valid ranges
from the full unicode database
(http://www.unicode.org/Public/UNIDATA/UnicodeData.txt and
http://www.unicode.org/Public/UNIDATA/Unihan.txt)
and with every release of pg, update the detection logic so only valid
characters are al
On Sat, 7 Aug 2004, John Hansen wrote:
> should not allow them to be stored, since there might me someone using
> the high ranges for a private character set, which could very well be
> included in the specification some day.
There are areas reserved for private character sets.
--
/Dennis Björk
4 actually,
10 needs four bytes:
0xxx 10xx 10xx 10xx
10 = 1010
Fill in the blanks, starting from the bottom, you get:
1010 1011 1011
Regards,
John Hansen
-Original Message-
From: Christopher Kings-Lynne [mailto:[EMAIL
Now it's entirely possible that the underlying support is a few bricks
shy of a load --- for instance I see that pg_utf_mblen thinks there are
no UTF8 codes longer than 3 bytes whereas your code goes to 4. I'm not
an expert on this stuff, so I don't know what the UTF8 spec actually
says. But I do
> Yes, but the specification allows for 6byte sequences, or 32bit
> characters.
UTF-8 is just an encoding specification, not character set
specification. Unicode only has 17 256x256 planes in its
specification.
> As dennis pointed out, just because they're not used, doesn't mean we
> should not a
Yes, but the specification allows for 6byte sequences, or 32bit
characters.
As dennis pointed out, just because they're not used, doesn't mean we
should not allow them to be stored, since there might me someone using
the high ranges for a private character set, which could very well be
included in
> Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> > ... This also means that the start byte can never start with 7 or 8
> > ones, that is illegal and should be tested for and rejected. So the
> > longest utf-8 sequence is 6 bytes (and the longest character needs 4
> > bytes (or 31 bits)).
>
> Tatsu
This should do it.
Regards,
John Hansen
-Original Message-
From: Dennis Bjorklund [mailto:[EMAIL PROTECTED]
Sent: Saturday, August 07, 2004 5:02 PM
To: Tom Lane
Cc: John Hansen; Hackers; Patches
Subject: Re: [HACKERS] UNICODE characters above 0x1
On Sat, 7 Aug 2004, Tom Lane wrot
[sorry if you get this mail twice, i think my first post didn't made it
passt the moderator queue]
Hi!
While playing around with 8.0devel I found it somewhat irritating that
psql had no tab-complete support for all tablespace related commands.
Attached is my own poor attempt that adds at least ba
Gavin Sherry <[EMAIL PROTECTED]> writes:
> Now, if for all the triggers on the base relation, !trigger->tgenabled is
> true, then newtuple will always be NULL.
Hmm ... seems like the all-triggers-disabled case should act the same as
the no-triggers-at-all case, which this doesn't seem to do. It d
On Sat, 7 Aug 2004, Tom Lane wrote:
> question at hand is whether we can support 32-bit characters or not ---
> and if not, what's the next bug to fix?
True, and that's hard to just give an answer to. One could do some simple
testing, make sure regexps work and then treat anything else that migh
53 matches
Mail list logo
