a
> column name? Thank you for any help!
There were some changes in the way variable references are resolved in
PL/pgsql in version 9.0; unfortunately, you seem to have run across
one of the cases where the new behavior requires more quoting than the
old one did.
--
Robert Haas
E
On Tue, Jan 17, 2012 at 1:23 PM, Noah Misch wrote:
> On Mon, Jan 16, 2012 at 08:54:53PM -0500, Robert Haas wrote:
>> On Sun, Dec 18, 2011 at 11:53 AM, Noah Misch wrote:
>> > Here's a version that calls sigsetjmp() once per file. ?While
>> > postgresql.conf
>
whichever way we go with
it seem like a good idea, too.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
be?
>>
>>> IMHO comment is wrong, code is in the right place.
>>
>> It used to be in heapam.h ... evidently, whoever moved it missed this
>> comment.
>
> I imagined that that was the case.
>
> It's a fairly inconsequential bug, but it is worth fi
ange introduced this problem, but you
could start by trying 8.2.23, 8.3.x, 8.4.x, etc. if you want to try to
figure it out.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To ma
kpoint activity).
Hmm, so what should we adjust it *to*?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
That seems a bit out of place to me, because that chapter is not
really about PL/pgsql, and OTHERS is not an exception name, just a
PL/pgsql construct. Maybe we could work a cross-reference into the
sentence that mentions PL/plgsql, though.
--
Robert Haas
EnterpriseDB: http://www.enterpr
long time. Then I broke installation.
> I've already tried to install with administrator account. No differernce.
>
> However, there is no such bug with v9.0.6.
Hmm, maybe initdb is hanging? Is there an installer log someplace,
perhaps in your temp directory?
Could you run:
initdb -
greSQL) 9.1.2
> contains support for command-line editing
>
> ADDITIONAL INFORMATION
> It also appears as though the header files are not cleanly installed. It
> looks like the 8.4 header files do not use symbolic links.
I think you will need to report this to the Ubuntu folks.
--
Ro
n:
>
> This URL for user groups is listed in several places. But it fails to load a
> web page.
>
> http://pugs.postgresql.org/
>
> I tried two browsers several times. Other pages at:
> http://www.postgresql.org/
> work well for me.
It is currently working for me.
--
Robert
the transaction
> immediately, not fetch some rows and then commit.
Is that even per spec? I would not expect the results, or the
side-effects, of a query to depend on the method used to retrieve its
results.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Com
ed problem... so I'd classify this more as an
unimplemented feature than a bug.
That having been said, I hope we'll get around to improving it at some
point. Even though in most cases inlining is a huge win, there are
certainly boundary cases where it's not, and this is one
\erofflps.txt
Since this is an English-language mailing list, you might want to try
your question here:
http://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Fri, Dec 23, 2011 at 1:58 PM, Heikki Linnakangas
wrote:
> On 23.12.2011 19:21, Robert Haas wrote:
>>
>> On Thu, Dec 15, 2011 at 3:40 PM, Holec, JPH Software
>> wrote:
>>>
>>> I Have PostgreSQL server 8.4.9 on Linux, database utf-8 and Client app on
>&
M:SS doesn't uniquely identify a point in time, even if you know
what time zone it's relative to. That combination of years, minutes,
days, hours, minutes, and seconds can occur twice, if it's near a DST
boundary.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterpr
n't work.
I think you need a "-c" in there somewhere, maybe something like this:
options='-cclient_encoding=WIN1250'
...although, for some reason, I can't get that to work from psql, even
though I can set other parameters using that syntax.
--
Robert Haas
Ente
it for
> upstream).
The PostgreSQL project doesn't have any direct control over Red Hat's
spec files, although Tom Lane, a PostgreSQL core team member, also
works at Red Hat. I would suggest that you take this up with Red Hat
directly...
--
Robert Haas
EnterpriseDB: http://www.ente
elp us guess what the relevant difference might be. The
debugger plugin *might* be relevant, but I think it's more likely a
red herring, and the real issue is something else entirely.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via
27;s
likely to lead to subtle bugs that are hard to find and perhaps
dependent on the exact compiler version used.
But I'm completely cool with doing this for platforms where we haven't
otherwise got an implementation. Any port in a storm.
--
Robert Haas
EnterpriseDB: http://www.enterp
t; if you need more details about the servers plz tell me and i will post
> them.any information that you may have is more than welcome. thx in advance
Could you send the output of pg_controldata on the standby, and also
the contents of pg_clog on that machine?
--
Robert Haas
EnterpriseDB: h
didn't close the application, weird things
occurred", it's kind of hard to figure out what exactly you did. If
you come up with a specific sequence of steps involving simple tools
like pg_dump and psql that produces a result you think is wrong,
someone here can probably (a) tell you wh
want more advice on this topic, I suggest posting to a more
appropriate mailing list with specific details of the problem you are
having.
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
vior wouldn't be very well-defined. It might be worth a TODO
>> to provide a better error message than "syntax error", though.
>
> Is it worth documenting, fixing, or adding this to the TODO list?
At most I would say we could try to improve the error message.
--
Robert H
On Wed, Nov 23, 2011 at 7:19 AM, Peter Geoghegan wrote:
> On 23 November 2011 02:49, Robert Haas wrote:
>> There is no sort of systematic labeling of error messages in the log
>> to enable the DBA to figure out that the first error message is likely
>> nothing more seri
tail_n_mail which, IIRC, has lots of hardcoded
error strings in it to help separate the wheat from the chaff, but
that's just a workaround for our failure to classify things properly.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsq
;
> Which SRID should we use for general purpose.
>
This mailing list is for bugs in PostgreSQL; it sounds like you have a user
question about PostGIS.
I think this might be the right place:
http://postgis.refractions.net/mailman/listinfo/postgis-users
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
nd write out
> dirty page (and that situation do not change overtime).
This sure sounds like a ring buffer is being used, suggesting VACUUM
or COPY IN activity.
What does pg_stat_activity say?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Compan
On Tue, Nov 15, 2011 at 5:16 AM, Heikki Linnakangas
wrote:
> NEW used to be a reserved keyword, but it's not so in 9.0 anymore. So 9.0
> pg_dump thinks it doesn't need to be quoted.
Why isn't it correct?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterpri
, so can you give us
some clues about what might be different in your environment?
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.
y only
tangentially related to PostgreSQL - if at all - I'm not sure.
Getting someone knowledgeable to sit down in front of the computer and
poke at it a bit seems likely to get you the results you are looking
for quite a bit more quickly.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
On Fri, Nov 4, 2011 at 1:21 PM, Tom Lane wrote:
> 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 t
any permissions. Our installers might, but probably
not on those directories, and you didn't use our installers anyway;
you used something provided by Holdem Manager, and I think you need to
complain to them, not us.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Po
s on inheritance children isn't supported, and you should
> not hold your breath waiting for it to be.
>
> 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 invo
it
would make it easier to help people.
The symptoms that you are describing sound pretty odd to me.
PostgreSQL is a database, not a piece of malware. How exactly did you
install it in the first place?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
risks for it.
I think my vote would be to just fix it in master.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Windows 7
> Description: quoting needed for column name with non ascii chars
> Details:
>
> I run sql from pg-admin:
>
> create table a(straßße int)
>
> On windows this creates a column which has empty name. However, it works
> well on Linux and Mac.
What happens if y
kage an ancient and out-of-date version of the software in a
non-standard fashion, so it's really impossible for us to give any
useful advice.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgre
On Mon, Oct 31, 2011 at 10:37 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Oct 30, 2011 at 11:39 PM, Maksym Boguk wrote:
>>> Seems index scan cannot stop after finding first NULL during scan on '>'
>>> condition, and doing scan through all 90% n
ms less than ideal. I suppose the problem is that we are
generating an index scan that starts at 0. and runs through the
end of the index, rather than stopping when it hits the first NULL.
Not sure how much work it would be to make that happen, but I guess
we'd need a second branch to t
ontain the actual value ( possibly changed by ALTER TABLE
> ... ).
Maybe I just need more caffeine, but I don't see what the problem is?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgres
can't do that for some reason, there's always auto_explain, but
that has some overhead and is a bit more work to set up.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql
herefore be marked as
> incorrect.
>
> Thanks for the support and replies on my work.
I would be curious to see (updated, corrected) results on older versions.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bu
configuration knobs are better (which most
PostgreSQL project members, inculding me, do not believe, because it
means more code to maintain and frequently confuses users to no
benefit) but rather that this particular configuration option is
needed to support some sensible use case that can
t document our way out of it.
(Hey, if SELECT .. ORDER BY .. FOR UPDATE can return rows out of order
and we can document our way out of that, this is small potatoes by
comparison.)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ruser without giving them replication privileges (or
revoke their superuser status without revoking replication
privileges), you need to specify both ALTER TABLE options.
All in all I'm somewhat inclined to think we should just patch the
docs. 9.1 hasn't been out for very long, so maybe
speculate on what the problem
might be here. I'm pretty doubtful that this is broken in general, as
that would mean that most of the extensions we bundle with core would
be broken on Windows, and I think someone would have noticed that by
now.
--
Robert Haas
EnterpriseDB: http://www.enterpr
ns to fix this issue.
What's your TEMP path set to? Can you write to that directory? Did
the installer leave behind a log file anywhere?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
t;>
>> So it looks like we're not successfully escaping characters on WIN1252.
>> The characters in question are also latin characters.
>>
>> We've reproduced this on a clean install.
>
> Has this been fixed?
I don't think so. It's not really c
sed as an expression
I've never really liked this behavior, but I don't have a clear idea
what to do about it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
the DB it is allowed . The
> field support because it is a oid type.
> Any suggestion?
> Thanks
I haven't seen any replies to this; you might want to try on the
pgsql-odbc mailing list, as this list is for bugs in the core
distribution.
--
Robert Haas
EnterpriseDB: http://www.ente
On Wed, Oct 19, 2011 at 8:30 AM, Robert Haas wrote:
> On Tue, Sep 27, 2011 at 12:05 PM, Craig wrote:
>>
>> The following bug has been logged online:
>>
>> Bug reference: 6228
>> Logged by: Craig
>> Email address: lumberjackches.
this problem. I think that this may be a windows
> issue rather than a postgre bug, but I thought I'd ask for help anyway.
> Thank you in advance for any advice.
I think this is one of the known issues with the 8.2 installer.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Ent
ssp/uuid.h presence... yes
> configure: WARNING: ossp/uuid.h: present but cannot be compiled
> configure: WARNING: ossp/uuid.h: check for missing prerequisite headers?
> configure: WARNING: ossp/uuid.h: see the Autoconf documentation
> configure: WARNING: ossp/uuid.h: section "Present But Cannot Be Compiled"
> configure: WARNING: ossp/uuid.h: proceeding with the preprocessor's result
> configure: WARNING: ossp/uuid.h: in the future, the compiler will take
> precedence
> configure: WARNING: ## ##
> configure: WARNING: ## Report this to pgsql-bugs@postgresql.org ##
> configure: WARNING: ## ##
> checking for ossp/uuid.h... yes
> checking whether byte ordering is bigendian... universal
>
>
> The compilation finished successfully, in spite of this warning. This is on
> an early 2008 Macbook Pro, 2.4GHz Intel Core 2 Duo processor, running Mac OS
> X Lion 10.7.1. Please let me know if you need any more information.
> -David Baumgold
Do you have config.log?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
2-16 (and just
ignore 120525) but it could also be interpreted to mean
2010121612-05-25, which is admittedly an awfully long time from now
but it doesn't seem any less logical than randomly throwing away part
of the input string.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
genunix`kthread_t * for identifier
> curthread: Module and program data models do not match
Neither this nor your other bug report from about the same time
contain enough information for anyone to troubleshoot the problem.
Please see:
http://wiki.postgresql.org/wiki/Guide_to_reporting_proble
: JDBC: blob doesnot work with bytea
> Details:
>
> To persist a blob you can also use bytea. Unfortunately the JDBC driver does
> not support this.
I think you'll need to raise this issue on the pgsql-jdbc mailing
list, as this list is only for bugs in the core distr
html
>
> http://archives.postgresql.org/pgsql-jdbc/2011-01/msg00065.php
>
> http://archives.postgresql.org/pgsql-bugs/2007-07/msg00104.php
I think you'll need to try the pgsql-jdbc list, as this list is only
for bugs in the core distribution.
--
Robert Haas
EnterpriseDB: http://ww
On Fri, Oct 14, 2011 at 12:29 AM, Vishnu S. wrote:
> The application deletes the contents of tables in the tablespace using
> DELETE TABLE query.
There's no DELETE TABLE command. Do you mean DELETE, or DROP TABLE?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The
that you typed to try to connect as that user, and then the
exact error message that you got would help a lot. Just off the top
of my head, a likely culprit is that you may need to adjust your
pg_hba.conf file.
http://www.postgresql.org/docs/current/static/auth-pg-hba-conf.html
--
Robert Haas
Ent
d patch will fix this issue.
Thanks, committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
eswitch.org/secure/attachment/14751/odbc.txt
This mailing list is for PostgreSQL bugs. We don't maintain unixODBC.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to
fixed for more than a
> year.
> Maybe the configure test doesn't work on Windows? I don't know.
On at least some Windows builds, configure isn't used at all... so
whatever values is being used would come from the MSVC build system.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Thu, Sep 29, 2011 at 7:23 AM, Yaamini Bist wrote:
> Hi,
> It would be really great if you can provide me information *Is PostGre
> compatible to RHEL 6.1 ?*
>
1. Yes.
2. This is not a bug.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
o insist that the input is in some particular
format, rather than just "whatever the input function will accept"...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make ch
On Fri, Sep 23, 2011 at 11:36 PM, YAMAMOTO Takashi
wrote:
> see the following patch.
> it seems some function names in the comment are out of sync with the reality.
Thanks, fixed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via
On Mon, Sep 26, 2011 at 12:20 PM, Robert Haas wrote:
> On Mon, Sep 26, 2011 at 12:17 PM, Merlin Moncure wrote:
>> hm. any relation to YAMAMOTO Takashi's recent email, [BUGS] bug in
>> plancache.c, which hasn't hit the archives yet?
>>
>>> "GetCachedP
and the code correctly, it's unsafe because the planner is
> destructive wrt the input tree. for my application, it often causes
> a crash in executor."
I was just wondering about that. It seems like it could very well be
the same issue, but I have not tested it yet.
--
Robert Ha
On Mon, Sep 26, 2011 at 11:40 AM, Robert Haas wrote:
> To check my work, I did this:
>
> --- a/src/backend/executor/execQual.c
> +++ b/src/backend/executor/execQual.c
> @@ -5003,6 +5003,7 @@ ExecQual(List *qual, ExprContext *econtext, bool
> resultForNull)
>
On Mon, Sep 26, 2011 at 11:00 AM, Robert Haas wrote:
> The whole thing is a bit mysterious because ExecQual() doesn't really
> do much that seems like it could generate an invalid memory reference.
>
> I'll poke at this some more...
I added some debugging code which set
1 0x0001001540fe in ExecScan (node=0x7fff5fbfde4f,
accessMtd=0x100167150 , recheckMtd=0x100166ef0 )
at execScan.c:195
195 if (!qual || ExecQual(qual, econtext, false))
The whole thing is a bit mysterious because ExecQual() doesn't really
do much that se
On Mon, Sep 26, 2011 at 12:45 AM, Ramanujam wrote:
> On Mon, Sep 26, 2011 at 9:57 AM, Robert Haas wrote:
>> Does it work if you use EXECUTE?
>
> Apologies to have not included the list when I replied to Pavel.
> Re-writing it as a dynamic sql stmt indeed works. Sorry for the n
> END;
>
> $BODY$
> LANGUAGE plpgsql VOLATILE COST 100 ROWS 100;
>
> Throws an error:
> NUM:42P02, DETAILS:there is no parameter $1
>
> Substrituting $1 with parm gives this error:
> NUM:42703, DETAILS:column "parm" does not exist
Does it work if you use EXECUTE
http://petereisentraut.blogspot.com/2008/03/readding-implicit-casts-in-postgresql.html
But in this case I think you're likely to still need a cast in there somewhere.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs maili
9-21 16:31:26.082048 | 2011-09-21 22:31:26.082048
(1 row)
The rules for interpreting time zone specifications are arcane enough
to make me suspect that this isn't a bug even though it seems rather
odd, but in any case it would be useful to know how many hours
PostgreSQL's timestamp is
On Wed, Sep 21, 2011 at 11:35 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Sep 18, 2011 at 5:10 PM, Robert Haas wrote:
>>> On Thu, Sep 15, 2011 at 12:05 AM, Tom Lane wrote:
>>>> In that case I'm betting Robert broke it somewhere in the unlogged-ta
On Sun, Sep 18, 2011 at 5:10 PM, Robert Haas wrote:
> On Thu, Sep 15, 2011 at 12:05 AM, Tom Lane wrote:
>> Alvaro Herrera writes:
>>> Excerpts from Abel Abraham Camarillo Ojeda's message of mié sep 14 18:33:33
>>> -0300 2011:
>>>> _n_srv=# creat
drop table pg_temp.c;
>>> DROP TABLE
>>> _n_srv=# create table pg_temp.c (x int unique);
>>> ERROR: temporary tables cannot specify a schema name
>
>> FWIW this does work in 9.0.
>
> In that case I'm betting Robert broke it somewhere in the unlogged
your explanation is
correct. Apparently the installation directory path and PGDATA path
locations have to patch the following regex:
^([a-zA-Z]:)\\([0-9a-zA-Z_\\\s\.\-\(\)]*)$
Sorry for the inconvenience. :-(
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Comp
xcited about that either ...
The fact that this code is poorly tested is exactly why I don't think
we should be complicating it with doodads of doubtful utility. The
existence of these Booleans causes people to use them. This probably
doesn't save any appreciable amount of performance, b
formation is no
> longer available.
I think it'd be worth actually having psql maintain the information
separately from the PGconn... but if nobody feels motivated to go do
that, doing at least this much would remove the foot-gun. So +1 for
that.
--
Robert Haas
EnterpriseDB: http://www.ent
On Tue, Sep 13, 2011 at 4:31 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sep 10, 2011, at 11:26 PM, Tom Lane wrote:
>>> (IOW, rather than "fix" this I'd prefer to rip out the code altogether.
>>> But maybe we should wait a couple more years for tha
On Sep 10, 2011, at 11:26 PM, Tom Lane wrote:
> Thom Brown writes:
>> I don't use rules, but in a bit of experimentation on Git master, I
>> discovered the following behaviour:
>
>> CREATE TABLE test1 (id serial primary key, things text);
>> CREATE TABLE test2 (id serial primary key, things text
w-unneeded segments) to take priority over
getting new ones.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
nk it's the latter. I have a vague recollection that we might
have left that undocumented on purpose, but I'm not actually sure why
we support it in the first place.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing l
postgresql.org/wiki/Guide_to_reporting_problems
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
in temporary schemas
>
> IIRC it was fixed in post-beta3. Robert?
Yeah, sorry about that. I really booted that one, but it was fixed
July 21st on REL9_1_STABLE.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing
question here:
http://archives.postgresql.org/pgadmin-support/
This list is only for bugs in PostgreSQL itself, and not all of the
pgAdmin developers read it regularly.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mail
On Wed, Jul 20, 2011 at 8:24 AM, Renzo Kottmann wrote:
> On 07/18/2011 05:25 PM, Robert Haas wrote:
>> On Tue, Jul 12, 2011 at 9:18 AM, Sandro Santilli wrote:
>>> Trying to exclude items from dumps of postgis-enabled databases
>>> we use pg_restore -l output and st
On Sun, Jul 24, 2011 at 5:06 PM, noordsij wrote:
>> Any idea what query triggered this?
>
> Only up to which stored procedure (which itself contains multiple
> statements).
If you provide a reproducible test case, we can probably get this fixed.
Otherwise, we probably can'
>
> I don't see any flaw in my logic. Postgresql doesn't seem to work correctly
> based on logic!
I can't help wondering if you are somehow getting bitten by the
strange semantics of NULL comparisons. Note that:
IF (something_that_is_null) THEN
...
END IF;
...will not t
in xmlParseBalancedChunkMemory () from
> /usr/local/lib/libxml2.so.
Any idea what query triggered this?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
t doesn't revoke privileges that user has granted: those
aren't considered dropable objects. So technically speaking all of
those commands are working just as expected.
Nevertheless, I agree with you that the behavior here leaves a lot to
be desired. Hunting down th
bit mingw-w64.
You might want to read this:
http://wiki.postgresql.org/wiki/Submitting_a_Patch
And add your patch here:
https://commitfest.postgresql.org/action/commitfest_view/open
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pg
nstaller distribution of PostgreSQL for Windows and is
> included as a contrib module with all versions of PostgreSQL 8.2 and above.
> However, if you are running any other ... "
>
> It is further good to explain what you loose when not installing the
> adminpack.
This is
designed to solve exactly this problem.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ii, n_ii * sizeof(INTERFACE_INFO),
&length, 0, 0)
Perhaps there's a better method we could be using, but I have no idea
what it is. A quick Google search didn't turn up any IPv6-related
restrictions on SIO_G
e on the parent table, then
> the relpages will be set back to zero, and the query will run slowly.
>
> Please let me know if you have any questions.
Tom fixed this in commit f3ff0433ab32fdc69da3c8f8e691ef6b4366559c on July 14th.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The
On Fri, Jul 8, 2011 at 5:21 AM, Kyotaro HORIGUCHI
wrote:
> Points to realize this follows,
Please add your patch to the next CommitFest.
https://commitfest.postgresql.org/action/commitfest_view/open
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Comp
On Tue, Jul 5, 2011 at 12:42 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Jul 3, 2011 at 12:31 PM, Tom Lane wrote:
>>> The code that recognizes a default expression as being just constant
>>> NULL doesn't think this is a constant NULL. In principle it
strict, but so far
> it has not seemed worth the trouble.
Gee, does Noah's recent patch adding the notion of "transform
functions" have any applicability to this problem?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
101 - 200 of 787 matches
Mail list logo
