Joshua Tolley writes:
> On Sat, Nov 27, 2010 at 11:23:46AM -0500, Tom Lane wrote:
>> There used to be a project of that name on gborg. I can't find the
>> source code anymore though.
> How about
> http://www.postgresql.org/ftp/projects/gborg/uniqueidentifier/stable/
hance it's a third party module that you didn't recompile for 9.0?
The magic-block mechanism should prevent that. What I'm wondering about
is whether the input function is (a) careless about null input and (b)
not marked STRICT.
regards, tom lane
--
Sent
; INSERT INTO tmp.amavis_user (id, email, priority, policy_id)
> VALUES (NEW.id, quote_literal(NEW.email), prio, 1);
Perhaps you tried to migrate away from using EXECUTE at the same time
you were converting to 9.0?
regards, tom lane
--
Sent via pgsql-bugs ma
atype that tries to return a constant string?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
'Foo Bar'.
Is this problem limited to \y, or do other regex operations that depend
on locale-specific character classification also not work for you?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
on of "in role" we use here is "has the privileges
of role". Since kaiting.chen is a superuser, all privilege tests will
succeed for him, including that one. IOW, a superuser is automatically
a member of every role. This isn't a bug.
regards, tom lane
e done to remove all of the files associated with dropped
> (temporary) tables _when_ the they are dropped?
Nothing other than forcing a checkpoint. There are
race-condition-related reasons for doing it like this, which I don't
have at the top of my brain, but you can find them in the archiv
.xx
> user=iamuser password=somepassword77 port=5432" will be truncated to
> "dbname=somebase host=xx.xxx.xx.xx user=iamuser password=somepas"'
Does this actually break anything, or is it just an annoying NOTICE?
When I try it here, I get the NOTICE as described, but
more than one worker). So you can end up computing a smaller value
on the next round. Lather, rinse, repeat.
Will fix. Thanks for the report!
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
d something about that. Thanks for the report!
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
se provide a complete test-case, not a vague description.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ustomer.cac_cert);
> explain update customer set login_name =
> (select "NESSOuserName" from person
> where person.cac_cert=customer.cac_cert);
That's not a bug.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To
in 9.0?
BTW, if the gripe is specifically about what happens in the pgAdmin UI,
another possible explanation is that pgAdmin changed. Can you reproduce
a change of behavior using just psql?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresq
al to make it so for wCTEs, but that doesn't mean
we should change the existing, documented and useful behavior of regular
CTEs.
(If you're wondering where it's documented, I cite section 7.8's
statement that only as much of a CTE query is evaluated as is read by
the parent
r bound
but perhaps it wouldn't be too painful to tweak it to allow the case.
It appears to be fairly hard to actually get a non-zero-D empty array
into the system, so while this is pretty ugly I think it wouldn't affect
common usage.
Comments?
regards, tom lane
ero-dimensional array? 0-D arrays might have been
unsupported at one time, but they're certainly considered valid now.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
hould be fixed
locally to those two types, rather than changing the behavior of
regular arrays.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
haven't dropped a level of indirect fetch
from your client code?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
rates whatever problem you're
actually having.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
E TABLE LIKE a lot?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
"Michael Feldmann" writes:
> [ pg_dump -c doesn't delete BLOBs ]
This appears to be fixed in 9.0. I fear it's impractical to do anything
about it before that, because pg_dump didn't treat BLOBs as first-class
objects before 9.0.
regards,
nt value of the lbound would be
indeterminate because it's off the end of the allocated space for a
zero-D array. But the code wouldn't be reaching that test.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to yo
Yeb Havinga writes:
> If there is going to be a patch fixing things, the value
> '{"1"}'::oidvector[] can't be exported and imported through binary send
> recv as well.
That's pilot error, nothing more nor less. (oidvector != oidvector[])
Heikki Linnakangas writes:
> On 11.11.2010 18:17, Tom Lane wrote:
>> BTW ... it strikes me there's another inconsistency between oidvectorin
>> and oidvectorrecv, namely that the former enforces a maximum of
>> FUNC_MAX_ARGS elements whereas the latter has no such l
rid of the former's maximum, but I'm worried about whether any code is
dependent on an assumption that oidvectors can't get toasted. The
type's marked untoastable in pg_type, so maybe enforcing the same limit
in the latter is a safer idea.
regards, tom lane
-
Heikki Linnakangas writes:
> On 11.11.2010 17:48, Tom Lane wrote:
>> The problem seems to be that array_recv passes back a zero-dimensional
>> array, *not* a 1-D array, when it observes that the input has no
>> elements. A zero-D array is not part of the subset of possi
t
intended for general-purpose use anyway. What's the use-case where this
would come up?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
function
is just completely bogus for the case of infinite slope. Will fix.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
out. If
you'd like us to believe we have something to fix, please exhibit some
SQL commands that deliver an incorrect result.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
the corner case
where the perpendicular would have infinite slope, and it is falling
through to the "take the nearer endpoint" case when it shouldn't.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
orm, same word size, and have the same
>>> configuration for certain settings like integer_datetimes.
> Can anyone suggest a way pg_upgrade could detect an upgrade from a
> 32-bit to 64-bit cpu and throw an error?
Surely it does that already, as a result of comparing pg_control
contents.
e uses. I think the default is to avoid
conversion, so this might be a dead end --- but if for instance you
had PGCLIENTENCODING set in the client environment, it could bite you.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Here's a proposed patch, sans documentation as yet.
> I see you took the surgical approach -- only a cast from a record to
> a character string type is affected. I agree that will fix the
> complaints I've
ation as yet.
regards, tom lane
diff --git a/src/backend/parser/parse_func.c b/src/backend/parser/parse_func.c
index b50bce448728280f63c695a688c004bd15bf84cf..9bb100e0c1e83c63b554f65300c03afed563373a 100644
*** a/src/backend/parser/parse_func.c
--- b/src/backend/parser/par
Dirk Heinrichs writes:
> Am 04.11.2010 04:55, schrieb Tom Lane:
>> I don't actually see any point in having two functions at all. Since
>> the trigger is examining the column type internally, it could perfectly
>> well do the right thing at runtime depending on col
Merlin Moncure writes:
> On Thu, Nov 4, 2010 at 12:14 PM, Tom Lane wrote:
>> "Kevin Grittner" writes:
>>> Merlin Moncure wrote:
>>>> create type x as (a int, b int);
>>>> select f((1,2));
>> I think Merlin probably meant to write
think Merlin probably meant to write "select x((1,2))", but that
doesn't work out-of-the-box either. What would be affected is
something like
select text((1,2));
which you'd now be forced to write as
select (1,2)::text;
(or you could use CAST notation; but
ad in mind: you still declare two functions at
> the SQL level, though.
I don't actually see any point in having two functions at all. Since
the trigger is examining the column type internally, it could perfectly
well do the right thing at runtime depending on column type.
0, at least for cases using UTF8 encoding.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
"Kevin Grittner" writes:
> Tom Lane wrote:
>> 3. Or, perhaps we could change recordDependencyOnSingleRelExpr so
>> that it generates a whole-table dependency on the target relation
>> even if there are no Vars in the expression. This would make it
>> act muc
bit tempted to go with solution #1, but we'd have to recognize
that probably every future use of recordDependencyOnSingleRelExpr would
be exposed to this same type of bug if it got too cute about eliminating
"redundant" dependencies. But at the same time, predicting what behavior
such
/*
* A whole-row Var references no specific columns, so adds no new
* dependency.
*/
if (var->varattno == InvalidAttrNumber)
return false;
This is broken at least as far back as 8.1. Surprising no one's noticed
before.
"spche" writes:
> Description:btree index search bug
I see no bug here. The cursor is opened at a time when there is one
row with a=3, so it can find only that one row because of its snapshot.
regards, tom lane
--
Sent via pgsql-bugs mailing lis
blem, it's unlikely that discussing trivial
examples like this will help get to the bottom of it. We'd need to look
at example tables that have realistic statistics.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
#x27; initscript,
I'd suggest putting the ulimit command in ~postgres/.bash_profile.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Greg Stark writes:
> On Thu, Oct 28, 2010 at 5:20 PM, Tom Lane wrote:
>> I experimented a bit with mysql's behavior, and it seems that (at least
>> in 5.1.51) what they do is treat "1and" or "2or" as if it were an
>> identifier. They're def
the same as every other boolean parameter. What I think
you are complaining about is not that, but that we don't rewrite the
source string into some standard format. That seems rather impractical
though.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bu
ore force when considering long-standing behaviors than things we just
recently introduced.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
e
> to something else.
Well, assuming for the sake of argument that we have consensus on fixing
it like that, is this something we should just do in HEAD, or should we
back-patch into 8.4 and 9.0? We'll be hearing about it nigh
indefinitely if we don't, but on the other hand this isn&
[ please continue any further discussion in pgsql-bugs only ]
"Kevin Grittner" writes:
> Tom Lane wrote:
>> BTW this seems pretty far off-topic for pgsql-performance.
> It is once you understand what's happening. It was probably the 11+
> minutes for the mistyp
ne of those.
In any case, a doc patch would be the right thing for the back branches.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
mention
of the case. Might be a good idea to change "generally" to "usually",
though, since "generally" might be read as implying that that's the
exact and only rule.
regards, tom lane
--
Sent via pgsql-bugs mailing lis
y will of course spit up later if the remainder of
the input is inconsistent with the assumption that that part is an
identifier. I don't have any other SQL DBMSes handy to experiment with,
but I wouldn't be surprised to find multiple behaviors out there.
regar
eaving out "unnecessary" spaces is a pretty common habit.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
so I guess both of these observations could
> well be caused by leftover partially completed operations.
Were there similar warnings on the master? Uninitialized-page warnings
are expected in certain error-recovery scenarios, but I'd be a little
worried if the slave appeared to be out
"Alan Choi" writes:
> psql stopped and quit if it encountered an invalid surrogate pair.
Fixed, thanks for the report!
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.p
o a symbolic interval
value.
The point of the age() calculation is to give you something that's
useful in human terms. It isn't necessarily going to work without
any surprises to do further arithmetic with it.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
roblem anyway.
> I'd be tempted to remove that caveat altogether for the same
> reason, but it's probably good to have that note there and just remove
> the sentence about query plans:
Agreed.
regards, tom lane
--
Sent via pgsql-bugs mailing li
with REINDEX after a database crash.
> They are also not replicated over streaming or file-based replication.
> For this reason, hash index use is presently discouraged.
s/this reason/these reasons/. Also maybe we should change this to a
or instead of just a ? Otherwise +1.
n practice, because they also have no WAL protection and don't
perform very well anyway. Why did you pick a hash index for a
production application?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscripti
duced since 9.10.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
that the alternatives have similar
performance anyway on their platform.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
porary
memory context during function inlining, and just accept that whatever
memory we chew up there is going to be leaked for the duration of
planning.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription
Brendan Jurd writes:
> On 25 October 2010 07:36, Tom Lane wrote:
>> I'm guessing it was modified in the temporary memory context and not
>> properly copied out to the parent context when we finished inlining
>> the function.
> Thanks for the hint; I found that t
erribly impressive one IMO.
> Of course the easiest way to fix this bug (or better flaw) is to change the
> documentation :-)
Yeah, that part of the docs will require editing no matter what we do.
I'm just trying to get some clarity on what the most reasonable behavior
is.
e current behavior is reasonable. VACUUM
FULL is (still) not intended as a routine maintenance operation, and
the point of that column is to track routine maintenance operations.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to yo
f7f7f,
tail = 0x7f7f7f7f}
I'm guessing it was modified in the temporary memory context and not
properly copied out to the parent context when we finished inlining
the function.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.
Craig Ringer writes:
> On 23/10/2010 1:11 AM, Tom Lane wrote:
>> Why do you expect that? The parameter only controls the *server*'s
>> output, it is not suggested anywhere that it should have an effect
>> on clients.
> I'm not at all sure what the right answer
er only controls the *server*'s
output, it is not suggested anywhere that it should have an effect
on clients.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
rade's scheme for getting the right
frozenxid values into the new catalogs, anyway?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Robert Haas writes:
> On Mon, Oct 11, 2010 at 7:50 PM, Tom Lane wrote:
>> Well, actually the btree_gist implementation for inet is a completely
>> broken piece of junk: it thinks that convert_network_to_scalar is 100%
>> trustworthy and can be used as a substitute fo
mposite types is probably a good two orders of magnitude
slower than comparing plain ints would be. I'm sure that coding
technique looks cute, but you're paying through the nose for it.
Consider making price_key a simple domain over int.
regards, tom lane
--
S
n as it sees a non-empty
bytea, so what's the use of trying to make the empty-string case
backwards compatible? It's probably better you find out about the
incompatibility sooner, so you can get on with fixing the real problem.
regards, tom lane
--
Sent via pgsql-b
Joel Lopes Da Silva writes:
> On Oct 18, 2010, at 7:16 AM, Tom Lane wrote:
>> What commands did you issue, exactly?
> I did:
> ./configure --enable-thread-safety \
> --with-openssl \
>
x27;s premature to speculate without facts as to what you did.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
hubert depesz lubaczewski writes:
> On Sun, Oct 17, 2010 at 11:10:09AM -0400, Tom Lane wrote:
>> Testing shows that that example fails in every Postgres release back to
>> 7.1. The spelling of the error message varies a bit, but they all agree
>> that a TZ format spec is
ails in every Postgres release back to
7.1. The spelling of the error message varies a bit, but they all agree
that a TZ format spec isn't supported.
I don't know what changed in your installation, but it wasn't this.
regards, tom lane
--
Sent via pgsql-bug
+ sin(radians(37.7438640))
* sin(radians(37.743864000))) - 1;
?column?
--
2.22044604925031e-16
(1 row)
As somebody already remarked, you need to use a version of that formula
that's less prone to roundoff error.
regards, tom lane
, or at least
doesn't work the way Postgres is expecting. I'd suggest leaving off
that configure option --- unless you really need it, in which case
you're going to have to track down the reason for the incompatibility.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
her problems. Maybe
you used a buggy compiler or some such. Did you build it exactly
the same way as you did 8.4.3, and with the same tools? Does it pass
the regression tests?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To ma
ed it like that instead of using the type's real
comparison functions, but it's pretty much useless if you want the
same sort order that the type itself defines.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to yo
;ve applied a patch.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
. I think SR is exposing a pre-existing problem here.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
f;h=3ab8b7fa6f9ac2fb04096f8860261dc42d59a570
which lobotomized plpython to not care about passing the right typmod to
I/O functions. This is a regression, and it's particularly annoying
because the other three standard PLs get this case right. Peter?
regards, tom
n't see any suitably cheap
place to insert the necessary processing, but after some reflection
and rejiggering of eval_const_expression's responsibilities, it's
done.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To mak
IS NULL" is the same as "x IS NOT NULL".
We don't expend an infinite number of cycles on rewriting different
query formulations into each other, and that's one of the ones we
don't handle ...
regards, tom lane
--
Sent via pgsql-bugs mailing l
and is extremely heavily exercised every day, the burden is on you
to demonstrate that there's a problem.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
you meant just "resultStatus" not
"result->resultStatus" in the if().
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ably values stability over corner cases like this one.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
name like
that. But you can do it, if you can figure out how to get Windows to
include a double quote in a command argument.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
LE myname SET statement_timeout = '5min';
>
> ==
Hm, looks like Bruce wasn't too awake the last time he made a
"proofreading" pass over that material. Fixed, thanks for the report!
regards, tom lane
--
Sent via pgsql-bugs ma
.
In short, what we've got here is a version skew problem. That doubtless
explains why Craig couldn't duplicate it on his Linux machine.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
t will prevent flattening and thus
prevent the sub-sub-query from getting duplicated.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ning the query.
> It looks like it's one of the helpers like the stats collector, autovac,
> bgwriter, etc. I'm unsure which yet.
I'd bet on autovacuum. You might be able to reproduce the crash in the
foreground process by issuing a manual VACUUM or ANALYZE.
Magnus Hagander writes:
> On Sun, Oct 3, 2010 at 00:52, Tom Lane wrote:
>> [ scratches head ... ] I don't see the problem.
> I think he's referring to the ability to flood the postgresql server
> with radius packets with spoofed IP source, correct?
Hm ... seem
e is the spoofing
possibility, and why would delaying the socket close accomplish
anything?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
rtainly wrong, but I don't see that complaint
here (on Fedora 13).
> The tiny change (attached) seems it fix it for me.
Agreed, this is a bug fix. Applied.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make change
already had some relevant locks, but you haven't
provided enough information to diagnose it beyond that.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
d it after the ALTER, a nicer fix doesn't seem
like a high priority IMO.)
Thanks for the report! It's too late for 9.0.1 but we'll do something
about this for 9.0.2.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To
this sort of thing has ever come up before. But certainly
we can expend a couple more bytes on that error message. Done in HEAD.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
1301 - 1400 of 7582 matches
Mail list logo
