On Sat, 2006-02-11 at 16:36 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I believe this is safe.
>
> I won't insult your intelligence by pointing out how I know that you
> didn't even test the patch against hash or gist.
I don't recall either way, though from what you say
I found it was easier to concatenate the "UNION" at the macro call site,
rather than the macro body. This eliminates the extra macro. Patch
attached and applied.
---
pgman wrote:
>
> Modified patch attached and applied.
>
On Sat, Feb 11, 2006 at 10:42:59PM -0500, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > Well, the attached patch removes the padding on the last column,
> > irrespective of the line. It will pad all the way to the end if the
> > cell is empty due to one of the earlier columns being multilin
Bruce Momjian writes:
> I found it was easier to concatenate the "UNION" at the macro call site,
> rather than the macro body. This eliminates the extra macro. Patch
> attached and applied.
Yeah, that looks like a much safer idea --- avoids making assumptions
about the behavior of the macro exp
Martijn van Oosterhout writes:
> About the ReportSyntaxErrorPosition thing, it was considered at the
> time (can't find the email right now) that control characters would be
> problematic but it wouldn't break anything that wasn't broken already.
> How tab was missed I don't know, nor a couple of
Tom Lane wrote:
> Martijn van Oosterhout writes:
> > About the ReportSyntaxErrorPosition thing, it was considered at the
> > time (can't find the email right now) that control characters would be
> > problematic but it wouldn't break anything that wasn't broken already.
> > How tab was missed I do
Hello All,
I'm proposing the fix of this bug:
http://archives.postgresql.org/pgsql-hackers/2005-02/msg00498.php
The exact SQL code exposing the error:
--
create table usno (ra real, dec real, bmag real, rmag real,ipix int8);
CREATE OR REPLACE FUNCTION xxx(refcursor) RETURNS refcursor AS
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> The problem with that is in fact in pl_exec.c in function
> compatible_tupdesc(), which do not check for the deleted attributes.
Is that really the only problem?
regards, tom lane
---(end of broadca
On Sun, 12 Feb 2006, Tom Lane wrote:
> "Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> > The problem with that is in fact in pl_exec.c in function
> > compatible_tupdesc(), which do not check for the deleted attributes.
>
> Is that really the only problem?
I cannot be completely sure in that,
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> This patch appears seriously broken, in particular every routine I
> >> looked at contained incorrect locking assumptions. Nor do I care
> >> for using pg_depend for the purposes it's being used for here.
>
> > OK, how do we procee
Patch applied. Thanks.
---
Joshua D. Drake wrote:
> Marc G. Fournier wrote:
>
> >
> > Is there a reason you didn't list the pl/PHP one? Seems appropriate
> > for that list no?
> >
> > On Mon, 6 Feb 2006, Joshua D. Drake
Change made.
---
Greg Sabino Mullane wrote:
[ There is text before PGP section. ]
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> > Perl - http://www.cpan.org
>
> Could someone please change this to:
>
> Perl
I have remove the LEFT part of the join to pg_roles in
psql/description.c. I assume this is too risky for 8.1.X.
---
Tom Lane wrote:
> Andrew - Supernews <[EMAIL PROTECTED]> writes:
> > On 2006-02-06, Peter Eisentraut <[EMA
Interesting. We should be able to handle a "" thousands separator. In
fact, psql does, but to_char() does not.
Looking at to_char(), it seems that we should be able to handle "" for
thousands and plus sign.
I have applied the following patch for 8.2. I have not applied to 8.1.X
because it is
Bruce Momjian wrote:
>
> I have remove the LEFT part of the join to pg_roles in
> psql/description.c. I assume this is too risky for 8.1.X.
Well, 8.1 already has per-role dependencies, so why not do it?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> >
> > I have remove the LEFT part of the join to pg_roles in
> > psql/description.c. I assume this is too risky for 8.1.X.
>
> Well, 8.1 already has per-role dependencies, so why not do it?
True, but if I messed up the SQL somehow, no one is testin
Would you eyeball it?
---
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> >
> > I have remove the LEFT part of the join to pg_roles in
> > psql/description.c. I assume this is too risky for 8.1.X.
>
> Well, 8.1 already has
The definitive answer can be found in the source code for the Darwin
kernel, xnu (links are below):
1. The shmmax, shmmin, shmmni, shmseg, and shmall settings cannot be
changed after the shared memory system is initialized
2. The shared memory system is initialized immediately after all 5
Bruce Momjian writes:
> I have applied the following patch for 8.2. I have not applied to 8.1.X
> because it is a behavior change.
This patch broke the regression tests. It seems to change the C-locale
behavior on many platforms.
regards, tom lane
-
Sorry, I had to revert this patch. C locale uses "" as "not
applicable", while French uses "" for "don't want". The C locale folks
rely too much on the existing behavior.
---
pgman wrote:
>
> Interesting. We should be ab
Bruce Momjian writes:
> Tom Lane wrote:
>> This patch broke the regression tests. It seems to change the C-locale
>> behavior on many platforms.
> Oh, so C locale has "" for thousands_sep? Hmm. So there is no way to
> disinguish "" as "don't have" from "" as "don't want". Will revert.
Possib
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> This patch broke the regression tests. It seems to change the C-locale
> >> behavior on many platforms.
>
> > Oh, so C locale has "" for thousands_sep? Hmm. So there is no way to
> > disinguish "" as "don't have" from "" as "don'
Tom Lane wrote:
> Bruce Momjian writes:
> > I have applied the following patch for 8.2. I have not applied to 8.1.X
> > because it is a behavior change.
>
> This patch broke the regression tests. It seems to change the C-locale
> behavior on many platforms.
Oh, so C locale has "" for thousands
On Sat, Feb 11, 2006 at 11:37:49PM -0500, Bruce Momjian wrote:
> David Fetter wrote:
> > On Sun, Jan 15, 2006 at 09:55:39PM -0800, David Fetter wrote:
> > > On Mon, Jan 16, 2006 at 12:13:11AM -0500, Neil Conway wrote:
> > > > On Sun, 2006-01-15 at 20:08 -0800, David Fetter wrote:
> > > > >
> > >
Bruce Momjian wrote:
I have remove the LEFT part of the join to pg_roles in
psql/description.c. I assume this is too risky for 8.1.X.
Well, 8.1 already has per-role dependencies, so why not do it?
I agree
---(end of broadcast)---
TIP 4: Have
Bruce Momjian wrote:
> > > Oh, so C locale has "" for thousands_sep? Hmm. So there is no way to
> > > disinguish "" as "don't have" from "" as "don't want". Will revert.
> >
> > Possibly we could special-case C locale, and allow an empty string only
> > when not C locale. However, it
Tom Lane <[EMAIL PROTECTED]> wrote:
> It's not saving any noticeable amount of code, and what it is doing
> is removing functionality we might want someday. It's not hard to
> imagine pgstattuple or VACUUM or other maintenance operations wanting
> to look at killed index entries.
I suggested it n
Bruce Momjian wrote:
> I looked this over and I am unsure what this does for us that isn't
> already accomplished using the wal_sync_method settings. See xlog.c for
> a description of O_DIRECT and when it is used.
I proposed it to supplement the cache control. There are some OSes that
supports
ITAGAKI Takahiro wrote:
> Bruce Momjian wrote:
>
> > I looked this over and I am unsure what this does for us that isn't
> > already accomplished using the wal_sync_method settings. See xlog.c for
> > a description of O_DIRECT and when it is used.
>
> I proposed it to supplement the cache contr
Daniel Verite wrote:
> Bruce Momjian wrote:
>
> > > > Oh, so C locale has "" for thousands_sep? Hmm. So there is no way to
> > > > disinguish "" as "don't have" from "" as "don't want". Will revert.
> > >
> > > Possibly we could special-case C locale, and allow an empty string only
> > >
30 matches
Mail list logo
