not be present in
the PDF generation process.
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
.
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
workaround you could just omit TRUE from CASE TRUE
WHEN ... it's a pretty redundant way to write the expression.
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
.
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
of the table's indexes
may have entries for it while others don't.
The correct invariant is that (a) if an index entry exists, there must
be a heap tuple for it to point at, and (b) a live tuple must have all
the index entries it should have.
regards, tom lane
--
Sent via
, 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
.
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
H.Merijn Brand h.m.br...@xs4all.nl writes:
On Thu, 16 Dec 2010 12:31:21 -0500, Tom Lane t...@sss.pgh.pa.us wrote:
So what I'm thinking is happening is that libpq expects size_t as
the argument type, but it's getting linked against a libc that
expects int as the argument type, and whatever HP
I'm
not particularly excited about fixing this one ... especially not in a
stable branch that's not getting a lot of developer testing anymore.
I'm inclined to leave this alone --- I think the risks of patching only
an old branch will outweigh the benefits.
regards, tom lane
about which
it should use?
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
Magnus Hagander mag...@hagander.net writes:
On Sat, Dec 11, 2010 at 18:31, Tom Lane t...@sss.pgh.pa.us wrote:
Hmm. I think that not resetting the n_tuples_xxx fields was simply an
oversight in Magnus' patch that added them,
http://archives.postgresql.org/pgsql-committers/2007-03/msg00144.php
.
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
/msg00144.php
Magnus, was this intentional by any chance?
However, I disagree with resetting last_autovac_time ... that's not a
counter, so there's no particularly good reason to discard its value.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
-table
last-vacuum times, so maybe discarding the database-level value too is
more consistent. Not sure.
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
Pavel Stehule pavel.steh...@gmail.com writes:
2010/12/9 Tom Lane t...@sss.pgh.pa.us:
What exactly is the use-case for that?
I am working on function that can help with record updating. It's
based on polymorphic types. I would to allow a multiple modification
per one call - like UPDATE
that we
should do something special with a parameter that happens to be an array.
Possibly variadic anyarray will do what you are after.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
]) --- real
call foo(10,20,20) -- but it doesn't work now.
I'm not convinced it should work that way. Even if you had convinced me
that this was sensible and had a real use-case, making it work like that
would take a whole bunch of mechanism that doesn't exist.
regards, tom
, 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
it wouldn't get indexed. So: commit.
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
Andres Freund and...@anarazel.de writes:
On Sunday 05 December 2010 17:42:59 Tom Lane wrote:
I think the reason the given example fails is just that it's all being
done in one transaction. If the null-containing row were known dead
it wouldn't get indexed. So: commit.
Um I doubt
Greg Stark gsst...@mit.edu writes:
On Fri, Dec 3, 2010 at 4:50 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Even if you're willing to
assume that the dictionary being used is the one defined by this
module, that dictionary depends on external configuration files
which are easily changeable.
Don't
misunderstand how triggers on inherited tables
work. A row-level trigger is fired for events on rows *in its table*.
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
as target.
2. If i create trigger FOR EACH STATEMENT, it will work ok for insert,
update and delete.
You mean FOR EACH ROW, no?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
are easily changeable.
Arguably it'd be reasonable to change the function's marking from
volatile to stable, but that's not going to be enough to allow use in
indexes.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
noticed
before. 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
that, or it's not going to get fixed.
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
are getting is *not* about a
bad password. It looks like you've neglected to provide a pg_hba.conf
entry that will allow dblink connections.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
download and compile all my needed functions,
The core uuid type has all that stuff except newid(), which we judged
not to be standardizable. You can find a few different uuid-creation
functions in contrib/uuid-ossp.
regards, tom lane
--
Sent via pgsql-bugs mailing list
Robert Haas robertmh...@gmail.com writes:
On Tue, Nov 23, 2010 at 10:29 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I believe the definition 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 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 via pgsql-bugs mailing list
Joshua Tolley eggyk...@gmail.com 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/
Ah, thanks
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
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 mailing list (pgsql-bugs
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
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
--
Sent via pgsql-bugs mailing list (pgsql-bugs
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 the connection
string still works.
regards, tom lane
, 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
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
.
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
!
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
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 make changes to your subscription:
http://www.postgresql.org
, 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@postgresql.org)
To make changes
this should 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
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
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
--
Sent via pgsql-bugs mailing list
.
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
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
Michael Feldmann michael.feldm...@uni-muenster.de 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, tom
CREATE 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
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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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 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
--
Sent via pgsql-bugs mailing
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Yeb Havinga yebhavi...@gmail.com 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[])
regards, tom
, the apparent 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 your
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 subscription:
http://www.postgresql.org/mailpref
. 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
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
. 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 make changes
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.
regards, tom lane
--
Sent via
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us 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 seen
).
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
Merlin Moncure mmonc...@gmail.com writes:
On Thu, Nov 4, 2010 at 12:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Merlin Moncure mmonc...@gmail.com wrote:
create type x as (a int, b int);
select f((1,2));
I think Merlin probably meant to write
Dirk Heinrichs dirk.heinri...@altum.de 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 column type.
Got
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
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.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us 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 much
spche sp...@163.com 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 list
, 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
too cute about eliminating
redundant dependencies. But at the same time, predicting what behavior
such uses might need is a tough game in itself, and maybe one that we
shouldn't get into now.
Any thoughts out there?
regards, tom lane
--
Sent via pgsql-bugs mailing list
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 changes to your subscription
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-bugs@postgresql.org
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
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
.
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
-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
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 of sync with the master.
regards, tom lane
--
Sent via pgsql-bugs
.
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
there.
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
. 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 list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
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
.
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
in 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 subscription:
http
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
Alan Choi alan.c...@emc.com 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
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 your
) 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.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
Brendan Jurd dire...@gmail.com writes:
On 25 October 2010 07:36, Tom Lane t...@sss.pgh.pa.us 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
to use a temporary
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
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.org)
To make changes to your subscription:
http
, 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
Craig Ringer cr...@postnewspapers.com.au 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 is here. I just
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
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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
Robert Haas robertmh...@gmail.com writes:
On Mon, Oct 11, 2010 at 7:50 PM, Tom Lane t...@sss.pgh.pa.us 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
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
Joel Lopes Da Silva j...@lopes-da-silva.com 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 \
--with-perl
as soon 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-bugs
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-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
hubert depesz lubaczewski dep...@depesz.com 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 isn't supported
1201 - 1300 of 6572 matches
Mail list logo
