nificant difference between the way that graphical
admin tools like pgAdmin view schemas and the way they look from psql.
In pgAdmin, you get a tree (which is how you seem to be thinking
about it), whereas in psql it tends to feel more like a flat namespace
that's constructed by smashing se
On Mon, Sep 27, 2010 at 12:44 PM, Ashesh Vashi <
ashesh.va...@enterprisedb.com> wrote:
> We're happy to see the problem resolved on your end. :-)--
>
However, it doesn't seem that we've actually done anything about the
underlying issue with pg_ctl.
--
Rob
sql.org/wiki/Guide_to_reporting_problems
http://www.postgresql.org/docs/current/static/bug-reporting.html
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
/Linux
>>
>> anfitrite:/opt# cat /etc/debian_version
>> 4.0
>
> Debian is not a supported platform for the installers - we don't see
> enough demand for it to justify the testing requirements I'm afraid.
So I think what that means for the OP is that
t catched my attention was
> MessageContext: 485902696 total in 6 blocks; 32160 free (16 chunks);
> 485870536 used
> which is well beyond the configured memory limits (280MB shared_buffers,
> temp 32MB, workmem 64MB)
Are you sure you meant to report this here? Seems like
On Wed, Sep 22, 2010 at 9:04 PM, Tom Lane wrote:
> Robert Haas writes:
>> Can SHOW return a NULL value, rather than the empty string?
>
> I think that would take some work in guc.c, and likely a redefinition
> of the API for show-hook functions. I'm not excited about d
looks like we have just one case to fix.
> Will get on it once I get my repo back together ...
Can SHOW return a NULL value, rather than the empty string?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ed on request of size 1048575996.
I'm not sure if there's a bug here or not, but it sounds like you're
out of memory. :-)
What is the value of maintenance_work_mem? How large is the table?
How much memory do you have on your machine? Exactly which 8.4
release are you running?
--
than the systems of people who are not having this
problem, because otherwise it's pretty hard to fix.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
views); you might want to look
at triggers instead. Rules are basically a crude query-rewrite
system. The rule rewriting process doesn't understand anything about
what your query is actually trying to do; it's just analyzing the
syntax (where, of course, the child tables aren't me
On Thu, Sep 16, 2010 at 9:30 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Sep 8, 2010 at 11:42 AM, Tom Lane wrote:
>>>> SELECT ROW(10, 'a') INTO b.b2; -- ok in 8.4 but fails in 9.0 [ERROR:
>>>> invalid input syntax for integer: "(10,a)
emented but don't hold your
> breath.
I wonder if Merge Append could be made to help with this case.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subs
ld be needed to restore the previous
> behavior. I'm inclined to say that the new behavior is more
> self-consistent and so we should call this a bug fix rather than a bug.
If we know the types of everything, is it possible to make both cases work?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
did you start the service?
And applying the good old Windows troubleshooting meme... if you
reboot, does that fix it?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
On Sun, Sep 12, 2010 at 12:40 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Aug 31, 2010 at 10:46 AM, Tom Lane wrote:
>>> We are not going to try to enforce uniqueness. This has been debated
>>> before, and most people like the current behavior just fine, or a
ut how to do
it, or that no one had written the patch, not that anyone thought the
current behavior was particularly desirable. What happens if you say
ALTER TABLE .. DROP CONSTRAINT or COMMENT ON CONSTRAINT? You just
pick one at random? That's really what most people want?
--
Robert Haa
you guys the captured image, i think it's good to link my question
> on StackOverflow website.
>
> http://stackoverflow.com/questions/3597000/postgresql-9-0-an-empty-row-with-
> null-like-values-in-not-null-field
Can you send us the results of:
pg_dump -t st_daily2
and the resul
;
> !!
At the risk of asking an obvious question, what are the contents of
that logfile?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.p
g the functions which fail for the automated analyze process.
> Can this be a search_path problem?
Maybe you should do ALTER FUNCTION name SET search_path = 'the right
search path' and see if that helps.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Po
On Sat, Feb 6, 2010 at 9:09 PM, Chris Travers wrote:
> On Sat, Feb 6, 2010 at 2:36 PM, Robert Haas wrote:
>> That's really odd. Nothing pgAdmin does should be able to crash the
>> PostgreSQL server, I would think. Have you got any custom code loaded
>> into Postg
On Wed, Aug 18, 2010 at 9:55 AM, Jens Wilke wrote:
> uuid-ossp.c:29:2: error: #error OSSP uuid.h not found
This seems like the one to look at. Perhaps you need to apt-get
install the package that contains that file.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterpr
0]
>
> If you're game, it might also be useful to see what the backend was up
> to when it crashed. There are some instructions on how to get a stack
> trace on the wiki:
>
> http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD
Y
understand the bug, but I will
> be happy to try to debug it further, if I am given a pointer as to how.
Well, obviously the best thing would be to isolate a reproducible test
case. But maybe a good start would be to try to get a list of the
exact series of SQL statements that are being execut
database objects other than tables. This would be good to
fix, but probably we'd need to start by coming up with a coherent
overall plan.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.o
it's in use.
Perhaps you need to stop the PostgreSQL service.
An even better idea might be to uninstall PostgreSQL using Add/Remove
Programs, or whatever uninstaller came with the installer you used.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
ach of those
> checks is un-cheap in itself, and if you blindly apply them at every
> node of an expression tree the cost will be exponential.
I think you'd need some kind of expression tree walker that builds up
a list of maximal stable subexpression trees. It would be nice to
figure th
On Thu, Aug 12, 2010 at 10:44 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Aug 11, 2010 at 5:12 PM, Tom Lane wrote:
>>> Yeah, possibly. It would probably be difficult for the planner to
>>> figure out where the cutover point is to make that worthwhile, though
On Wed, Aug 11, 2010 at 5:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> In theory, the optimization Brian wants is possible here, right? I
>> mean, you could replace the functional call with a Param, and pull the
>> Param out and make it an InitPlan. Seems like that wo
ide more details to get help, and it would also be
a good idea to post to the correct mailing list, which is
pgsql-performance.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
---
Function Scan on f (cost=0.25..12.75 rows=5 width=4) (actual
time=34.585..51.972 rows=1 loops=1)
Filter: (f = 1)
Total runtime: 63.277 ms
(3 rows)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@
Param, and pull the
Param out and make it an InitPlan. Seems like that would generally be
a win, if you figure to loop more than once and the execution cost of
the function is not too tiny.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent v
me* that
the results won't change for a given set of arguments, not that it is
*required to prevent* it from being called multiple times with the
same set of arguments.
You can certainly prevent the function from being inlined, though
(perhaps, by writing it in PL/pgsql).
--
);
create table bottom () inherits (top1, top2);
alter table bottom no inherit ;
If = top1, then bottom.a should now allow nulls, but if
= top2, then it should still be not null. Unfortunately,
we don't do enough bookkeeping right now to distinguish those cases.
--
Robert Haas
EnterpriseDB:
unlike in the case of "explain" ?
Well, you should be able to find all the calls to ExecutorStart() by
using grep. But it sounds like you might be better off implementing
this as an executor hook. Or perhaps one of the existing ones
(auto_explain or pg_stat_stateme
ions, but you
haven't provided enough details to speculate in detail (for example,
perhaps you could reply to the list and post a copy of the script you
think is doing this).
Also, I'm pretty sure that we don't have a directory called
pg_twoface, though it would pretty funny if we di
hether the .bat file association is going
> to start the right program, or the right program should be included in the
> parameter passed to the .Run function.
Is this the EDB one-click installer you're using, or something else?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
ore like your installer isn't
configuring it properly.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ORDER BY; ORDER BY must appear after all
> regular arguments of the aggregate.
Could we arrange to emit this error message only when there is an
aggregate with the same name but different arguments?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Com
On Wed, Aug 4, 2010 at 6:19 PM, Tom Lane wrote:
> for: tgl, josh, badalex, mmoncure
> against: rhaas, thom
> Anybody else want to vote, or change their vote after seeing the patch?
If we're not regarding this as beta-forcing, I abstain.
--
Robert Haas
Ente
the
> "most important" argument first, and no one would see the delimiter
> as the most important one.
Well, it would match the syntax of things like perl's join(). But I
think that's probably not enough reason to go fiddling with it.
--
Robert Haas
EnterpriseDB: http
e will be rc1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres 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 Wed, Aug 4, 2010 at 1:04 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Aug 4, 2010 at 12:44 PM, Tom Lane wrote:
>>> Robert Haas writes:
>>>> I suppose this confusion is only possible because string_agg has both
>>>> a one-argument and a two
On Wed, Aug 4, 2010 at 12:44 PM, Tom Lane wrote:
> Robert Haas writes:
>> I suppose this confusion is only possible because string_agg has both
>> a one-argument and a two-argument form.
>
> Right, or at least that's what allows the mistake to go through without
08)...
Sorry, there is no such mode...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres 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 Wed, Aug 4, 2010 at 11:29 AM, Tom Lane wrote:
> Robert Haas writes:
>> Oh, yeah. I guess you need this:
>
>> select thing, string_agg(stuff, ',' order by stuff) from agg_test
>> group by thing;
>
>> Rather than this:
>
>> select thing,
the second one is supposed to
mean, but I remember this was discussed before. Perhaps we need a
somewhere about multi-argument aggregates.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
On Tue, Jul 27, 2010 at 7:27 PM, Tom Lane wrote:
> Robert Haas writes:
>> Does it help if you put a CHECK (false) constraint on the parent table?
>
> It won't --- it'll still result in an append plan even if there's only
> one surviving child.
>
> This i
Seq Scan on FACT_TABLE
> (cost=100.00..110.02 rows=1 width=186)
> Filter: (day = 20100502)
> -> Seq Scan on FACT_TABLE_20100502 FACT_TABLE
> (cost=100.00..1084220.62 rows=1876985 width=4
> 1)
>
as type OID? Then it
would be hard to tell whether migration was safe or not. Perhaps the
right long-term solution is to try harder to preserve OIDs in more
cases.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-bugs mailing list (pgsq
the other icons.)
>
> I hopefully may report this subject on this place, because it is an overall
> problem with the installation of postgresql with all the modules using this
> type of icon.
>
> Thank you
> regards
> *** heinz ***
PostgreSQL itself doesn't have icons.
hould probably choose a
more appropriate mailing list on which to ask this question. You'll
probably have better luck if you provide a few more details about what
your setup is and what you're trying to do with it.
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
--
Robert
what that the above is doing, it looks like some kind of
> installer...
The installer apparently isn't too smart, either, because the
second-to-last name of our product is the 17th letter of the alphabet,
not the 15th.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
n xid to get calculated
> (heap_(insert|update|delete) basically) after youre deeply stacked.
Thanks, perfect. Committed and back-patched to 8.0.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.or
On Thu, Jul 22, 2010 at 5:01 PM, Robert Haas wrote:
> On Mon, Jul 19, 2010 at 4:35 PM, Andres Freund wrote:
>>> Well. I got that far. But why is that something worthy of support?
>>> For one I have a hard time imaging a sensible use case, for another doing
>>>
atch
this. The proposed patch applies only as far back as 8.3, due to the
lazy XID assignment changes in that version, but it looks like the bug
exists all the way back to 8.0. It looks like only minor adjustments
are required for the older branches, though. 7.4 is not affected, as
it does not h
1 row on the inner side - it could be less.
But I agree with you that the estimate of 1000 doesn't seem to make
much sense. I'm not sure where that's coming from.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-bugs mailing
and on
> million records works 7 sec)
>
> SELECT d1.ID, d2.ID
> FROM DocPrimary d1
> JOIN DocPrimary d2 ON d2.BasedOn=d1.ID
> WHERE (d2.BasedOn=234409763) or (d2.ID=234409763)
EXPLAIN ANALYZE output for both queries, please?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
why
> is permission denied ?
>
> the set role is in a security invoker function before the delete statement.
> Could this be related in anyway ?
I tried it here and it worked for me. Can you provide a
self-contained test case?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
Th
x86_64 (MacOS 10.6.4)
> Description: Makefile.darwin broken
> Details:
>
> Makefile.darwin references src/backend/postgres, which doesn't exist.
So what, specifically, is not working for you? I'm using MacOS X
10.6.4 x86_64 also, and I can build Postgres without a p
work but doesn't.
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres 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, Jun 24, 2010 at 11:02 PM, Robert Haas wrote:
> On Thu, Jun 24, 2010 at 4:50 PM, Chris Browne wrote:
>> alvhe...@commandprompt.com (Alvaro Herrera) writes:
>>> Excerpts from Chris Browne's message of jue jun 24 14:40:30 -0400 2010:
>>>> robertm
On Thu, Jun 24, 2010 at 4:50 PM, Chris Browne wrote:
> alvhe...@commandprompt.com (Alvaro Herrera) writes:
>> Excerpts from Chris Browne's message of jue jun 24 14:40:30 -0400 2010:
>>> robertmh...@gmail.com (Robert Haas) writes:
>>> > This patch makes it clea
;s a patch that makes this more version-sensitive.
This patch makes it clear that the workaround is no good on AIX 6.1,
but it doesn't seem quite clear about whether the underlying problem
has been fixed in AIX 6.1. It would be good to understand that.
--
Robert Haas
EnterpriseDB: http:
l-odbc/
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ry this question on the pgsql-odbc mailing list.
http://archives.postgresql.org/pgsql-odbc/
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Why do you think that? I tried both the example you gave here and the
example from your followup email on the 15th in 9.0beta, and the
behavior seems correct there.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-bugs mailing
like it might be an npgsql problem. I confess I
don't know the first thing about npgsql. I think this might be their
mailing list though - maybe you want to try there?
http://pgfoundry.org/mailman/listinfo/npgsql-devel
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Post
you mean that YOU don't ever do that. What everybody else
does is up to them, and there are plenty of people on this thread
saying either (1) they don't want to do what you're proposing or (2)
their application doesn't need fixing because it already quotes
everything.
--
R
#x27;t using --quote-like-crazy. Not sure if we want to go there,
though.
The idea mentioned on another part of this thread of providing a way
to separate schema and data dumps without tanking performance is a
good one, too, but I still think this has merit even if we do that.
Just because we m
On Thu, Jun 10, 2010 at 9:39 AM, Tom Lane wrote:
> Robert Haas writes:
>> I believe this is the commit:
>
>> http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=3a524653d18f29676b91f740634a673b72beb6b5
>
>> It looks like the code was changed, but I don
will tell me my system administration practices suck,
but people do these kinds of things, in real life, all the time.
Maybe if we all had an IQ of 170 and an infinite hardware budget we
wouldn't, but my IQ is only 169. :-)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The En
/gitweb?p=postgresql.git;a=commit;h=3a524653d18f29676b91f740634a673b72beb6b5
It looks like the code was changed, but I don't see any doc updates.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ed out the DDL for particular objects
just to look at it, for example. However, I emphatically do NOT agree
that leaving someone with a 500MB dump file (or, for some people on
this list, a whole heck of a lot larger than that) that has to be
manually edited to reload is a useful behavior. It
On Wed, Jun 9, 2010 at 4:48 PM, Robert Haas wrote:
> On Wed, Jun 9, 2010 at 4:47 PM, Dean Rasheed wrote:
>> On 9 June 2010 20:56, Robert Haas wrote:
>>> On Wed, Jun 9, 2010 at 3:50 PM, Tom Lane wrote:
>>>> Dean Rasheed writes:
>>>>> Hmm. Well it&
On Wed, Jun 9, 2010 at 4:47 PM, Dean Rasheed wrote:
> On 9 June 2010 20:56, Robert Haas wrote:
>> On Wed, Jun 9, 2010 at 3:50 PM, Tom Lane wrote:
>>> Dean Rasheed writes:
>>>> Hmm. Well it's quite subjective, but IMO it's already more readable
>>&g
On Wed, Jun 9, 2010 at 9:35 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> > I think users would rather have the restore fail, and know right away
>> > they have an issue, than to do the upgrade, and find out later that some
>> > of their application queries fa
On Wed, Jun 9, 2010 at 9:10 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Sun, Jun 6, 2010 at 2:53 PM, Dimitri Fontaine
>> wrote:
>> > Robert Haas writes:
>> >>> Well as Bruce said this option won't solve the OP's problem, unless the
>&
re variables that worry me.
Passing down information about which things are known constants seems
more complicated to me than just getting the quoting rules right in
the first place. If you look at the patch I proposed, you'll see that
it's really quite simple and only a slight tighte
On Wed, Jun 9, 2010 at 12:58 PM, Robert Haas wrote:
> On Wed, Jun 9, 2010 at 12:57 PM, Dean Rasheed
> wrote:
>> On 9 June 2010 17:52, Robert Haas wrote:
>>> On Wed, Jun 9, 2010 at 12:25 PM, Tom Lane wrote:
>>>> Robert Haas writes:
>>>>>
On Wed, Jun 9, 2010 at 12:58 PM, Robert Haas wrote:
> On Wed, Jun 9, 2010 at 12:57 PM, Dean Rasheed
> wrote:
>> On 9 June 2010 17:52, Robert Haas wrote:
>>> On Wed, Jun 9, 2010 at 12:25 PM, Tom Lane wrote:
>>>> Robert Haas writes:
>>>>>
On Wed, Jun 9, 2010 at 12:57 PM, Dean Rasheed wrote:
> On 9 June 2010 17:52, Robert Haas wrote:
>> On Wed, Jun 9, 2010 at 12:25 PM, Tom Lane wrote:
>>> Robert Haas writes:
>>>> On Wed, Jun 9, 2010 at 11:14 AM, Tom Lane wrote:
>>>>> Why not? Sure
On Wed, Jun 9, 2010 at 12:25 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jun 9, 2010 at 11:14 AM, Tom Lane wrote:
>>> Why not? Surely we can restrict EXPLAIN's set of key names to be safe.
>
>> It seems to me that it would be easy for a future pa
On Wed, Jun 9, 2010 at 11:14 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jun 9, 2010 at 11:03 AM, Tom Lane wrote:
>>> I still agree with Dean's original proposal: always quote the values of
>>> strings.
>
>> I'd still rather rip the format
On Wed, Jun 9, 2010 at 11:03 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jun 9, 2010 at 9:35 AM, Dean Rasheed
>> wrote:
>>>> Does anyone care that Alias will sometimes be a string, and sometimes a
>>>> number?
>
>> After further rev
On Wed, Jun 9, 2010 at 10:52 AM, Dave Page wrote:
> On Wed, Jun 9, 2010 at 3:50 PM, Robert Haas wrote:
>> On Wed, Jun 9, 2010 at 6:09 AM, Dave Page wrote:
>>> Please provide a password for the database superuser (${superaccount})
>>> and service account (${servi
On Wed, Jun 9, 2010 at 1:14 AM, Tom Lane wrote:
> Robert Haas writes:
>> It's possible. I don't really see a reason not to add an = operator
>> for XML - does anyone else?
>
> Yes, that was considered and rejected, IIRC. What is your definition
> of equal
y user-friendly at all. And we get questions about it here
regularly. Why not:
If (account exists)
prompt user to log into account
else
tell user account will be created, ask for account pw
prompt user for db superuser pw
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise P
ally I'm the only one who needs to read it,
> so the TEXT format will remain my preferred option.
>
> I was just doing some random beta testing, working through the list of
> cool new features.
Quick, somebody give this man a cigar!
--
Robert Haas
EnterpriseDB: http://www.enterprisedb
On Wed, Jun 9, 2010 at 8:46 AM, Dean Rasheed wrote:
> On 9 June 2010 03:48, Robert Haas wrote:
>> please test.
>
> Well your patch definitely fixes my original bug, and AFAICT always
> produces valid YAML output now. I've only found one case where a
> particular parser
On Wed, Jun 9, 2010 at 7:23 AM, Dean Rasheed wrote:
> On 9 June 2010 12:07, Robert Haas wrote:
>> On Wed, Jun 9, 2010 at 2:58 AM, Dean Rasheed
>> wrote:
>>> On 9 June 2010 03:48, Robert Haas wrote:
>>>> Er, I should also say, thanks for the report, and pl
On Wed, Jun 9, 2010 at 2:58 AM, Dean Rasheed wrote:
> On 9 June 2010 03:48, Robert Haas wrote:
>> Er, I should also say, thanks for the report, and please test. I am
>> definitely not an expert on YAML.
>>
>
> I'm not an expert on YAML either, but I don't t
tc).
It's possible. I don't really see a reason not to add an = operator
for XML - does anyone else?
It would need to be done by updating src/include/catalog/pg_*.h,
rather than via SQL, of course.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Com
ve ser "limpa" ou seja, deletados todos os registros
> existentes.
This is an English-language mailing list, but you could try here:
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Com
minIII pero no puedo crear una base de
> datos porque cada vez q lo intento me sale el mismo error.
>
> Tambien entre por modo a prueba de fallos y busque todo lo que tuviera
> nombre postgres y lo elimine y volvi a instalar pero nada me funciona..que
> puedo hacer??
Por favor pregunta aq
eves installed postgres before. What kind of password is that? I can't
> install postgres here.
I feel like we've had this question a few times before, and answered
it, but I'm not a Windows guy and can't remember the answer. Can we
add an FAQ entry for this, or somethin
what happened, CLUSTER on the table might be enough to fix
the problem.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres 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 Tue, Jun 8, 2010 at 10:47 PM, Robert Haas wrote:
> On Mon, Jun 7, 2010 at 4:14 AM, Dean Rasheed wrote:
>> Testing 9.0 beta, I found that EXPLAINing certain queries in YAML
>> format will produce invalid YAML, for example:
>>
>> explain (format yaml) select * fro
; Patch attached.
I've committed a patch which I think will address this issue without
uglifying the output quite so much. Also, I didn't like the idea of
not applying escaping to both the keys and values, even though we
think we'll never have a key that requires escaping. With thi
lly about
whether implicit casts to and from text are a good idea or not. The
OP obviously thinks they are, and everyone else (whether they agree
with the behavior or not) is trying to explain the reasons why we
don't have them.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The
more we make the YAML
format look like the JSON format, the less water that argument holds.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
401 - 500 of 787 matches
Mail list logo