here, but what should the error say exactly? Can we get any info
more detailed than failed to apply stylesheet?
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
failed to apply stylesheet?
Apparently not -- or at least, if libxslt provides any easy way to
extract error reports, it's not evident from the pretty-awful
documentation. I've committed a fix that just reports failed to apply
stylesheet.
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
worth fixing anyway,
to keep the compilers happy or in case of future code calling
buildACLCommands() or parseAclItem().
Agreed.
Attached is a patch to hopefully fix those two errors.
Applied, thanks.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
that can
fail for some inputs, possibly the best solution is to mark the function
volatile so that the planner will avoid rearranging stuff that uses it.
This might do some considerable damage to the overall quality of the
plan though.
regards, tom lane
--
Sent via pgsql-bugs
complains about those
functions and tells you to remove them by hand is far safer than
creating blind spots in pg_dump.
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
against using an inner
relation with a non-flat distribution.
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
time.
Failure of the restore process is a failure, we do not retry.
(The general theory is that if you think you need retries, you
should code the restore_command to handle that.)
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
allows to insert two NULLs in such column.
Oracle is not exactly the most standards-compliant implementation
around. They are well-known to be particularly wrong with respect to
NULLs behavior.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
that reference indeterminate versions
of files?
See detailed error paths in the attached html reports.
There were no html reports attached, and I'd prefer plain text
anyway please ...
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
?
It has no control over people overwriting its executable files.
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
Tomas Vondra t...@fuzzy.cz writes:
On 30.5.2012 22:35, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz writes:
whenever I run a C-function (part of an .so file) and the file is
overwritten, the connection crashes. Tested on 9.1.3 and 9.2-beta1.
What exactly would you expect Postgres to do about
that way, we surely ought to reload it. I've not looked at the
code yet, but from memory we allow +/-14 hours as a sane range. Looks
like maybe we'd better run through all the Olson entries and see what is
least sane ...
Will fix, thanks for the report.
regards, tom lane
.
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
schema in your search path. It might
help to do \df one in psql to see what you've got.
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
this.
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 one in public, ie
drop function public.plpython_call_handler();
The other two are what the language is actually using nowadays.
Hopefully pg_upgrade will then cope with upgrading them ...
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
Jeff Frost j...@pgexperts.com writes:
On May 24, 2012, at 3:35 PM, Tom Lane wrote:
Jeff Frost j...@pgexperts.com writes:
BTW, when I connected to it this time, I had a really long time before my
psql was able to send a query, so it seems to be still broken at least.
Yeah, I was afraid
is the transcript -
Is it possible you've got silent_mode enabled in postgresql.conf?
That's the only thing I can think of that would make it do that.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription
.
No, that has certainly never been the default.
FWIW, we removed that setting entirely as of 9.2.
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
occurrence --- I think an autovacuum
on one of the system catalogs would trigger that, for example.
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 start
script he's using depends on it (if so, he's going to have some work to
do when 9.2 hits).
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
Jeff Frost j...@pgexperts.com writes:
On 05/24/12 12:21, Tom Lane wrote:
How big is pg_attribute normally in this database? I'm suspicious that
what triggered this is some major bloating of pg_attribute (and maybe
some of the other catalogs too).
So, the current working system's
Jeff Frost j...@pgexperts.com writes:
On May 24, 2012, at 3:13 PM, Tom Lane wrote:
Huh. A bit bigger, but not by that much. It doesn't seem like this
would be enough to make seqscan performance fall off a cliff, as it
apparently did. Unless maybe the slightly-bloated catalogs were just
in an SCM) rather than hope that
pg_dump's output will still be useful for the other systems.
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 that, keeping the original source
file is the way to go.
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
.
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 Tue, May 22, 2012 at 4:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
heapgetpage() seems like the most reasonable place to me, as there we'll
only be making the check once per page not once per tuple.
ok. this fixes the issue:
Well, actually it needs
, 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
) before
making the volatility test, cf commit 5a86e5e19. The reason the
subselect flattening code has difficulty with this case is that that
happens before function inlining does, so the expression still looks
volatile even though it really isn't.
regards, tom lane
--
Sent via
' directly to tsquery, which is what's going to
happen in the first example, you get the lexeme 'europe' which doesn't
match 'europ'.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
.
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
, if you really are running 8.4.0, you would be well advised to
update to a newer minor release. The 8.4 release series is currently at
8.4.11, meaning you're missing 11 minor versions worth of bug fixes,
some of which were pretty critical.
regards, tom lane
--
Sent via
=postgresql.gita=commitdiffh=672def62259354f28000e8cfb97b6668192369c2
In theory at least, you should only get a NULL back if there's
insufficient memory to create a PGconn object at all.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
effort on. We might at some point consider
introducing a different type that could handle variable length data
... although it's not clear that text or bytea couldn't meet the
apparently limited need.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
entries.
This is not a fire and forget type of feature, it requires nontrivial
effort on the part of the extension author to make it useful. Please
see
http://www.postgresql.org/docs/9.1/static/extend-extensions.html#AEN51978
regards, tom lane
--
Sent via pgsql-bugs
.
I believe this is a consequence of commit
a4cd6abcc901c1a8009c62a27f78696717bb8fe1, which introduced the entirely
false assumption that --schema-only and --data-only have something to
do with the order that entries appear in the archive ...
regards, tom lane
--
Sent via
.
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
from the above-mentioned page and drop them into
the timezone directory in your installation.
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
was shipped
in 8.3.8, 8.4.1, and later releases. We have not heard reports of this
failure from anyone running newer releases.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
is that its
behavior can be changed with ALTER TEXT DICTIONARY. This wrapper
function doesn't eliminate that risk (in fact it adds some new ones),
so it doesn't look very safe to me.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
.
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.05.2012 16:52, Tom Lane wrote:
IMO, no part of the system should ever get within an order of magnitude
of holding 100 LWLocks concurrently.
I agree we should never get anywhere near that limit. But if we do -
because
usage that needed to be
rewritten anyway. That is *not* good evidence for adding complexity
and cycles to the mechanism to make it more failsoft. It shouldn't
need to be failsoft.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
. We need to see a complete *self
contained* test case, such as a SQL script that creates a set of objects
that don't dump correctly.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
-function arguments in the future. People would be more likely
to get excited about that if you were to offer a strong use-case why
it's important to not just write bigint[] here.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
Robert Haas robertmh...@gmail.com writes:
On Wed, May 2, 2012 at 6:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The only way we could suppress such warnings would be if we made
tab-complete.c use E'' strings for literals containing name prefixes;
which is perhaps doable but it would mean having
instead of
creating the view.
Please provide a concrete example.
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 worse than the disease.
In general, it's bad design to use a BEFORE trigger to propagate changes
to other rows; you should do that in AFTER triggers. See the
documentation.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
logic for the particular opclass? Maybe that's something to fix, too.
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
to be done, in such a way that it doesn't break
the existing working cases while fixing their case.
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
, but presumably the
alternatives were worse.
I'm inclined to think that if we got this far without complaint, there's
not a lot of point in writing new string-escaping support to solve what
is now a legacy problem.
regards, tom lane
--
Sent via pgsql-bugs mailing list
that symptom, but it is fixed in
recent update releases. What PG version are you running? If it's
not at least one of the releases cited below, update.
regards, tom lane
Author: Tom Lane t...@sss.pgh.pa.us
Branch: master [08e261cbc] 2011-11-01 19:49:58 -0400
Branch
, 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
to get held long, ever. Could you check all the Postgres
processes and see which of them have backtraces different from that?
We need to figure out what's sitting on that lock and why.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
:531, at least for a first pass. Calls from
elsewhere in bufmgr.c might be more interesting, and anything that's not
blocked at an LWLockAcquire at all might be even more interesting.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
, 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
or
something.
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
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
a problem with cleaning them up.
The pg_namespace entries are deliberately left there across sessions,
to avoid useless catalog churn.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
for calling this malformed input?
(We're in agreement that the current behavior is wrong, though.)
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 is no supported method for changing the order of attributes in a
composite type, so I wonder exactly how you did step 4. If it involved
direct manipulation of the system catalogs, I would say this falls in
the category of if you break it, you get to keep both pieces.
regards, tom
.
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
lots of ALTER OWNER commands.)
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
RHEL5, but on recent Linuxen you can
check the process's signal masks like this:
grep ^Sig /proc//status
where is the logging collector's PID. Could we see that?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
this as a back-patchable bug
fix, or a definition change suitable only for HEAD?
regards, tom lane
diff --git a/contrib/hstore/hstore_io.c b/contrib/hstore/hstore_io.c
index dde6c4b376ea2a82ed7d3cc0ef040e52f4df393a..08eafa18f1600d21e35eb4c3298215318dfebd9d 100644
*** a/contrib
Josh Berkus j...@agliodbs.com writes:
On 4/26/12 5:50 PM, Tom Lane wrote:
check the process's signal masks like this:
grep ^Sig /proc//status
where is the logging collector's PID. Could we see that?
SigQ: 0/399360
SigPnd:
SigBlk:
SigIgn
strace --- if that's available, just watching the collector
process while you send it SIGHUP might be informative.
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
directory if it's not there ... but only once, during startup. Should
we have it repeat that after a SIGHUP?
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
Log_directory changes,
but I don't see that there's more that can be done about this kind
of situation.
BTW, what log messages were you getting exactly? I'd have expected
something about could not open log file as well as the disabling
automatic rotation one.
regards, tom lane
with abusing
the system like that, if you wished.
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
, and I don't see why that's ad-hoc. In general the planner has to
check the volatility status of any expression it's going to try to
reason about.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
Peter Eisentraut pete...@gmx.net writes:
On tor, 2012-04-19 at 15:00 -0400, Tom Lane wrote:
i+pgb...@avdd.tk writes:
A concurrent psql session will overwrite the history of the first. This
does not look good: a database tool causing me to lose my data!
Works okay for me. I suspect you need
eshkin...@gmail.com writes:
set timezone to 'W-SU'; select '2011-03-27 23:00:00'::timestamptz;
SET
timestamptz
2011-03-28 02:59:54+04
I've applied a patch for this. Thanks for the report!
regards, tom lane
--
Sent via pgsql
which states execution of a SELECT is carried only as far as the
primary query demands its output.
If I change the function to say WITH ... SELECT * FROM locked then
blocking occurs as expected.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
. You can certainly
put a query into a function invoked by CHECK. It may be that there's
some particular use-case that this doesn't work for, but that does not
justify a blanket statement that it doesn't work.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
array slot must chance to have
a sane value in some environments.
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
imagine your Debian package
is also, while the machines that are happy are not.
So: some platform-specific misbehavior here. I have no time to poke at
it more now, though. Who else can reproduce this, on what platforms?
regards, tom lane
--
Sent via pgsql-bugs mailing
to be libreadline's
problem not ours.
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
messages are always the same
That only suggests a new incoming connection, which seems probably
unrelated. However, if that new connection is what's going to examine
pg_attribute, maybe the issue is that it's looking before the ALTER has
committed?
regards, tom lane
is independent of the main (and the fact that they happen to have
the same columns is NOT good enough to make it acceptable to a function
declared to take the main table's rowtype).
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
Robert Haas robertmh...@gmail.com writes:
On Thu, Apr 5, 2012 at 2:39 AM, Hitoshi Harada umi.tan...@gmail.com wrote:
On Wed, Apr 4, 2012 at 8:00 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Given the lack of complaints since 9.0, maybe we should not fix this
but just redefine the new behavior
Andrey Mitroshin m...@akamit.com writes:
But 9.0.7 compiles fine. 8.4.11 too.
That's fairly irrelevant, since the code that wants to use wcstombs_l()
and mbstowcs_l() is new in 9.1 (it's part of COLLATE-clause support).
regards, tom lane
--
Sent via pgsql-bugs mailing
;
end loop;
end;
$BODY$
LANGUAGE plpgsql;
Works for me in 8.4.11 (after correcting record_var.id - record_var.pid
at line 6). Maybe you need to update to some more recent version than
8.4.0.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
question is whether you're really running 8.4.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
. Is that not the case on AIX? It would be pretty
bizarre if not.
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
commands won't prevent that, they'll at worst result in some NOTICEs
during the reload.
In short, I'm not real sure this should be considered a bug.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
consider
backpatching it. You should probably back off the cost assigned to the
noaccent function as a workaround.
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
, it could well lead to a backtrace like this.
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
equivalent to the built-in ones as far as results go, they are not
equivalent in terms of their ability to match to indexes. But not
sure how we turn that observation into useful documentation.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
could still argue that it's nondeterministic, but the
nondeterminism is at least mostly hidden from users. I've removed
that sentence and adjusted some other places to match.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes:
commit 337b6f5ecf05b21b5e997986884d097d60e4e3d0 marked comparetup_datum
should not be called but actually it is called for eg. tape-based sort.
Yeah, that's pretty broken. Patch applied, thanks!
regards, tom lane
are wider than one example in the SPI docs.
Thoughts?
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
.
Lose the BEGIN and it will probably work more nicely.
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
trivial to build RPMs for
the particular architecture you are using --- basically you just point
rpmbuild --rebuild at the SRPM.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
Jeff Davis pg...@j-davis.com writes:
On Sat, 2012-03-24 at 19:07 -0400, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
Surely we don't want it to be set from the environment, right?
Why not?
I agree that we shouldn't change the documented behavior of those GUCs.
But a SQL command
and the pg_verifymbstr call. However,
this is dependent on the parsing loop never having a reason to throw
error, which at the very least is something that needs a comment.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
501 - 600 of 6572 matches
Mail list logo
