have loaded them. (In this case
* we will emit a parameterless CREATE LANGUAGE command, which will
* require PL template knowledge in the backend to reload.)
*/
An actual add-on procedural language would not fall foul of this.
regards, tom lane
--
Sent via pgsq
e current transaction is rolled back.
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
says there are parsing conflicts if we try to not
require the parens, and that SQL:2008 doesn't actually require anything
beyond a simple integer constant 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
#x27;t a
simple integer constant. I'll apply a patch to make that a bit more
obvious.
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
forgetting that
backslash is an escape character in Postgres string literals, and
also for LIKE itself. You should reread the manual's discussion of
LIKE:
http://www.postgresql.org/docs/8.4/static/functions-matching.html
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
fer pointer returned by BufHdrGetBlock is bad,
and how could that happen? I'm suspicious that there must be something
broken about your VM environment. Can you reproduce it outside the VM,
or even better create a reproducible test case?
regards, tom lane
--
deadlock in the postmaster log. We're
not going to change it in 8.3.x 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
Josh Kupershmidt writes:
> On Wed, Nov 30, 2011 at 9:17 PM, Tom Lane wrote:
>> Can you try that on 9.1 branch tip to see if it's already fixed?
> Hrm, don't think that helped - I get the same error in the logs using
> a checkout of branch REL9_1_STABLE.
Well, was
Josh Kupershmidt writes:
> I have a new 9.1.1 hot standby machine (VM). It consistently starts
> up, goes through recovery through these same WAL segments, and then
> gets a "Bus error":
Can you try that on 9.1 branch tip to see if it's already fixed?
to do something about that. Best advice
is to avoid ambiguous input, or if you can't, at least avoid flipping
your datestyle on the fly.
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
Maxim Boguk writes:
> Is that fix will be included to the next minor versions releases?
Yes, it's in already:
http://git.postgresql.org/gitweb/?p=postgresql.git
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
=
> prolang) as lanname FROM pg_catalog.pg_proc WHERE oid =
> '16386'::pg_catalog.oid
> LOG: statement: SELECT pg_catalog.format_type('1185'::pg_catalog.oid, NULL)
> LOG: statement: SELECT pg_catalog.format_type('1022'::pg_catalog.oid, NULL)
> LOG: st
. Committed at
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=871dd024a6adf7766702b1cdacfb02bd8002d2bb
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
l fix it?
I think you have some dangling entries in pg_depend --- manually
deleting any rows that reference the missing pg_extension OID should fix
it.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
ht
P on
the object will encounter the extension at outermost recursion level.)
So the problem seems to be only due to your ALTER EXTENSION DROP command
having left an incomplete set of extension dependencies behind.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@p
Ronan Dunklau writes:
> How will this bug be handled with regards to releases ?
It'll be fixed in next week's releases.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.p
n
pg_dump. Usually we prefer to retrieve names from the server as-is,
then apply fmtId() when printing them --- this is more flexible than
having possibly-pre-quoted names in pg_dump's internal state.
Will fix it the latter way. Thanks for the report!
regards, tom lane
--
"Sidar Lopez" writes:
> Operating system: Mac OS X
> Description:Startup Script
> Log file is not being created at ${PGLOG} location.
Hmm, yeah, that's overly-quoted. Will fix, thanks for the report!
regards, tom lane
--
Sent via
might think that, but you'd be wrong :-(. ginRedoUpdateMetapage
is failing to restore the contents of the pending-list correctly,
which means this is broken for all types of GIN indexes. Will fix.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@p
lindebg writes:
> On 11/19/2011 04:34 AM, Tom Lane wrote:
>> Color me skeptical. Under what conceivable use-case could you have
>> functions that were mutually dependent in that way? And actually did
>> something useful (not recurse till stack overflow) when called?
>
;s not in any stable branch. It seemed like enough of a
behavioral change to be too risky to put into minor releases.
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
expect. In the new coding, an argument is considered terminated
only by unquoted whitespace or backslash.
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
u have
functions that were mutually dependent in that way? And actually did
something useful (not recurse till stack overflow) when called?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.po
here are ways to do
> that correctly -
Has anybody suggested raising the log_min_messages setting?
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
he next set of update releases, or if you're in a big
hurry you can get the patch here:
http://archives.postgresql.org/pgsql-committers/2011-10/msg7.php
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
I wrote:
> You might possibly want to spell
> the above as SET comment = '...' || coalesce(comment, null) ...
Sheesh. coalesce(comment, '') of course. Need more caffeine.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postg
red that concatenation of a
null with something else yields null. You might possibly want to spell
the above as SET comment = '...' || coalesce(comment, null) ..., if you
want to pretend that a null is the same thing as an empty string.
regards, tom lane
--
Se
command was: COPY public.new (f1, new) TO stdout;
The least painful solution might be to always quote *every* identifier
in commands sent to the source server, since we don't especially care
how nice-looking those are.
regards, tom lane
--
Sent via pgs
ing at 0.
I failed to reproduce this here, and a look at the code responsible for
xid epoch maintenance reveals no obvious way that it could have been
bypassed. So there's some fairly critical piece of context that you're
not telling us ...
regards, tom lane
--
Sent vi
Peter Eisentraut writes:
> On tor, 2011-11-10 at 19:30 -0500, Tom Lane wrote:
>> I think psql only pays attention to its locale when stdout is a tty.
>> Now *why* it acts like that, I'll leave for Peter to defend.
> We would have to review the original discussion
-c 'show client_encoding' | head -10
> client_encoding
> -
> KOI8R
> (1 row)
I think psql only pays attention to its locale when stdout is a tty.
Now *why* it acts like that, I'll leave for Peter to defend.
regards, tom lane
--
"Maksym Boguk" writes:
> Description:Is ALTER ROLE set client_encoding broken in 9.1?
No, but I think psql prefers to set its encoding according to its locale
enviroment these days.
regards, tom lane
--
Sent via pgsql-bugs mailing lis
etup64 = /usr/lib64/libodbcpsqlS.so
FileUsage = 1
Depending on which build of postgresql-odbc you're using, the driver
library file might be named psqlodbcw.so instead; but in any case
libodbcpsql.so is not something to trust.
regards, tom lane
--
Sent
Robert Haas writes:
> On Thu, Nov 3, 2011 at 5:07 PM, Tom Lane wrote:
>> We probably ought to have something in there to throw an error ...
> Probably not for rules in general, but we shouldn't let people turn
> tables into views if they are involved in table inheritance,
r breath waiting for it to be.
We probably ought to have something in there to throw an error ...
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
o error.
Right offhand I would guess that you are using an old JDBC driver that
isn't prepared for standard_conforming_strings to be turned on.
If that isn't it, I'd suggest asking for help on the pgsql-jdbc mailing
list; I'm not sure how many of those guys read pgsql-bugs.
tch, and just say that the
performance problem is only going to be addressed 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
pm into SUSE 11 SP
> 1.
> But adminpack.sql is not found.
It's called adminpack--1.0.sql these days, and is installed using a
different command than your version of pgAdmin is probably trying
to use.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql
Robert Haas writes:
> On Mon, Oct 31, 2011 at 12:43 PM, Tom Lane wrote:
>> A patch along these lines should be pretty localized. Has anyone
>> got an opinion on whether to back-patch or not? This seems like a
>> performance bug, but given the lack of prior complaints,
ocalized. Has anyone
got an opinion on whether to back-patch or not? This seems like a
performance bug, but given the lack of prior complaints, maybe we
shouldn't take any risks for 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
the zeroth-order version
of recombining them). So either my analysis was wrong at the time,
or some later change has eliminated the need for two flags, or the
regression tests aren't covering the problematic case. Will investigate
further once I've absorbed some caffeine.
a value had been negative. AFAICT there are no such
locales anyway, other than POSIX for which we definitely don't want to
believe the empty-string setting.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your su
ingle byte.
Does anyone know of locales where the decimal point isn't a single byte?
I'm wondering if that assumption needs to be got rid of 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
;localhost" means the local machine; there are Internet standards
saying so. On the other hand, client applications that assume the
database server is on the same machine they are on are definitely
broken, and need to be fixed.
regards, tom lane
--
Sent via pgs
fundamental problem with that kluge (and yes, it's a kluge) is that
it supposes that you migrated EVERY local service to the other machine.
Which, obviously, you did not.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
Robert Haas writes:
> On Thu, Oct 27, 2011 at 6:15 PM, Tom Lane wrote:
>> Noah Misch writes:
>>> I think we should merge #3 into #2; nothing about the REPLICATION setting
>>> justifies a distinct paradigm.
>> Yeah, there's much to be said for that. I tho
f this much
information.
> btw: The database uses plpython and postgis.
Hmm, did you change postgis versions at the same time? If so, which
upgrade caused the problem, postgres or postgis?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql
privilege that superusers might not have was pretty bogus to start with.
rolcatupdate isn't a very good precedent to rely on because it's never
been documented or used to any noticeable extent, so there's no reason
to think that it provides a tested-and-accepted behavior.
iented
standards. But it's wrong, no matter how many places say that. Ask an
astronomer rather than a computer scientist, if you're not convinced.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your su
atch the
> docs. 9.1 hasn't been out for very long, so maybe expectations aren't
> too settled yet, but changing security-critical behavior in back
> branches doesn't seem like a wonderful idea; and I think I mildly
> prefer the current semantics to the proposed ones.
nd
while searching the RFC archives.)
And, given that we've been doing it this way since 2001 without
previous complaints, the number of systems that fail to do it
must be pretty small.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To ma
y events as old as three days.
> Can the second (16384 -> /db/base/main) link be safely deleted?
If there's no matching entry in pg_tablespace then it should be junk.
But you might want to check for pg_class entries with reltablespace =
16384 before pulling the trigger.
7;10s'
> auto_explain.log_analyze = true
> auto_explain.log_buffers = true
> As the postgres user, issue "pg_ctl reload"
> pg_ctl status will now show that there is no running postmaster.
This looks like the same thing as bug #6097, which is fixed in 9.0.5.
ny
freshly-created self-referential FK constraint is vulnerable to the same
problem; in particular the problem would come back if you did a dump and
reload.
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
atabase with LC_COLLATE and LC_CTYPE set to 'C'.
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
tly in Postgres, because there's no difference (in 8.3 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
"Maksym Boguk" writes:
> Somehow pg_database_size producing results which are 2Ñ
more then reality.
I can't reproduce any such problem here. I suspect you overlooked some
tablespaces in your manual "du" commands.
regards, tom lane
--
Sent
lative pathname to start
the postmaster, unless you plan to start it from the same working
directory every time.
We could possibly avoid this by having pg_ctl try to absolute-ify the -D
setting during postmaster start, but I'm not convinced it's worth the
trouble, or even that it's
LTER them to be one, they will NOT have the replication
> permission and cannot be used as a replication user until you explicitly
> grant that permission.
That doesn't sound to me like a bug. These flags are independent, we
just provide a certain default at role creation time.
the argument that people coming from Sybase-ish DBs might be
confused by this; but the current arrangement is also confusing lots
of people, so I don't think that argument has all that much weight.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsq
not me personally, so replying only to me isn't going to get you
anywhere. Please keep the list cc'd when replying.
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
n the wrong place), the command works.
In that case you're dealing with a libedit bug. libedit has a lot of
known problems, especially if you're trying to use an old version as
it sounds like you might be. There's not a lot we can do about that.
regards, t
"large database" means
little, and it certainly doesn't explain why you're seeing it when
nobody else has reported any such thing.
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 of SELECT.
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
/lib/pgxs/src/makefiles/pgxs.mk:164: warning: ignoring old
> recipe for target `uninstall'
> make[1]: Nothing to be done for `all'.
You probably need to report that to the postgis folk, not here.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-b
e
functionality of executing a SELECT and discarding the result simply
isn't there.
So at this point it looks like we made up PERFORM out of whole cloth,
and we could just as easily choose to do it another way. Jan, do you
remember anything about the reasoning for PERFORM?
ldn't be an unreasonable thing to just interpret a SELECT
with no INTO clause as being a PERFORM (ie execute and discard results).
Then we'd not have to do anything magic for commands starting with WITH.
regards, tom lane
--
Sent via pgsql-bugs mailing list (
e responsibility
of having a non-buggy bison available.
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 Young writes:
> I've update my m4 to version 1.4.13
> from:
> http://ftp.openbsd.org/pub/OpenBSD/4.9/packages/amd64/m4-1.4.13.tgz
> the problem solved perfectly!
Just for the archives' sake, can you confirm which m4 version you had
before?
g some openbsd-specific copy of m4, but GNU m4 1.4.4, and that the
problem is not reproducible with newer versions of m4. So what it seems
to boil down to is "get a newer m4". Especially if you've got 1.4.4.
regards, tom lane
--
Sent via pgsql-bugs mailing list (
Robert Young writes:
> On Tue, Oct 18, 2011 at 18:22, Tom Lane wrote:
>> Hmm, what version of bison are you using?
> # /usr/bin/bison -V
> bison (GNU Bison) 2.3
> Written by Robert Corbett and Richard Stallman.
> Copyright (C) 2006 Free Software Foundation, Inc.
> Th
posed patch seems to me
to be making more assumptions about what bison will emit (specifically,
about the ordering of various code blocks) than what we're doing now.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to y
be your worst problem.
AFAICT the SQL standard is perfectly clear on this. *Values* of type
varchar can be of zero length, but that does not mean that you can
*declare* a column to be varchar(0), and that NOTE says specifically
that you can't.
regards, tom lane
--
Sent
. If that's the right
guess, you need to do CREATE EXTENSION citext FROM unpackaged
to fix 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
Laerson keler writes:
> 2011/10/17 Tom Lane
>> "Laerson Keler" writes:
>> Why did you do that, that is what were you trying to accomplish? It
>> never did block nextval() on the sequence, for example.
> Tom Lane, good afternoon, I block the sequence not to m
can I enable the blocking of the sequence?
Why did you do that, that is what were you trying to accomplish? It
never did block nextval() on the sequence, for example.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make ch
ooked in the win64 patches.
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
ession=# \d foo
Did not find any relation named "foo".
regression=# \d :foo
Did not find any relation named "bar".
\copy is different because it uses OT_WHOLE_LINE mode to read the
argument, and that doesn't expand :variable references. I'd be a bit
leery of chan
, this is a "your transaction is holding too
many locks" problem (namely, one lock for each transient table). Please
follow the advice given in the error message.
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 a feature. The only way to prevent it would be to not fire
triggers for updates caused by FK actions, which would be a cure worse
than the disease.
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 targeting a
nonempty subdirectory of $PGDATA/base to create a new database in.
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 was built
separately from his pg_dump executable?
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
ions, and probably some other cases too because there
seem to be multiple instances of the dubious coding. It's a bit hard to
believe that nobody's noticed that before.
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 writes:
> [ we forgot to record dependencies on function default expressions ]
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.postgresql.
7;s the standard contraction for "if and only 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
eferenced from table "derived".
The reason for that is that the DO ALSO action occurs before the main
action, so you're trying to delete a "referenced" row that is in fact
still referenced. One solution would be to declare the foreign key
constraint as DEFERRABLE INITIA
ssuming that it will always be resolved the way
you want ... but if you can't be bothered to do that, using text instead
of varchar as the column type would avoid most of the cases where you'll
see something like this.
regards, tom lane
--
Sent via pgsq
Peter Geoghegan writes:
> On 29 September 2011 23:15, Tom Lane wrote:
>> Looks like I broke it here:
>> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=1cb108efb0e60d87e4adec38e7636b6e8efbeb57
> Hmm. Although it was obvious to me that this was an internal
) sub
> group by schemaname
> This produces the internal error message "no relation entry for relid
> 1". Why is that?
Looks like I broke it here:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=1cb108efb0e60d87e4adec38e7636b6e8efbeb57
Fixed, thanks for
trib regression tests, so there's not anything too obviously broken
about the idea.
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
ay to suppose that collation
can be ignored when matching to a collation-less index? If not, what's
the correct rule? I don't like the idea of concluding that hstore has
to be forcibly assigned a collation just because it has some operators
that accept text ...
er
disappear from the index, short of a REINDEX; and this is also the worst
case for index corruption, since we must be able to compare other OID
values to the non-leaf-page entry to figure out which leaf page to
descend to in searches.
In short, the reason why this type of code hasn't been
mp at all? The timestamp input
converter is perfectly capable of dealing with standard formats like
-mm-dd, and it does what most people expect in the way of data
validation checks.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
ID counter wrapped
around, you'd be pretty well screwed. As Alvaro says, manual
alterations of the system catalogs never have been supported, meaning
that we will never offer a guarantee that something that (more or less)
worked in a previous release will still work in newer ones.
stgresql 9.1 - false.
It sounds like you didn't use the same locale settings when creating
your 9.1 database. Check LC_CTYPE and LC_COLLATE settings.
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
header);
COPY 1
regression=# copy tenk1 to '/dev/null' with (format csv, header true);
COPY 1
regression=# copy tenk1 to '/dev/null' with (format csv, header false);
COPY 1
Also,
regression=# copy tenk1 to '/dev/null' with (oids fals);
ERROR: oids r
3 is horribly obsolete,
and you should at least update to the end of the 8.1 release branch
if you can't easily migrate to a supported branch.
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 wrote:
> bricklen writes:
>> Is this a bug,
> Yes. Thanks for the test case, will look.
Fixed, patch is at
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=1679e9feddc94bd7372a6829db92868e55ef7177
regards, tom lane
--
Sent via pgsql-
bricklen writes:
> Is this a bug,
Yes. Thanks for the test case, will look.
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 work on a fix? I expect you are plenty busy with commitfest
> stuff, but please let me know otherwise.
I have what-I-think-is-the-fix pretty clear in my own mind, so let me
give it a try. If it doesn't work I'll bounce it back to you.
regards, tom lane
--
S
801 - 900 of 7582 matches
Mail list logo
