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's quite subjective, but IMO it's already more re
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
>>> than JSON regardless of whether or not values are quoted, simply
>>> because it doesn't have [ ] and { }
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
than JSON regardless of whether or not values
"David Gardner" writes:
> Description:plpythonu gives cache lookup error
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.org/mailpref/pgsq
The following bug has been logged online:
Bug reference: 5497
Logged by: David Gardner
Email address: dgard...@creatureshop.com
PostgreSQL version: 9.0beta2
Operating system: Debian Linux
Description:plpythonu gives cache lookup error
Details:
hdpsdb=# CREATE OR REP
The following bug has been logged online:
Bug reference: 5496
Logged by: Sunny
Email address: goodmeet7...@naver.com
PostgreSQL version: 8.4
Operating system: windows xp
Description:Link does not open though wish to use following site
Details:
Link does not open tho
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 fail and they need to run around fixi
Alvaro Herrera wrote:
> Excerpts from Bruce Momjian's message of mi?? jun 09 21:10:21 -0400 2010:
>
> > 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 fail and they
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 fail and they need to run around fixing
> > them. ?(FYI, pg_upgrade would use the new pg_dump an
Excerpts from Bruce Momjian's message of mié jun 09 21:10:21 -0400 2010:
> 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 fail and they need to run around fixing
> them.
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
>> >>> application he's using for managing the backups
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
> >>> application he's using for managing the backups do use the option.
> >>
> >> Well, that's a pretty trivial ch
On 10/06/10 02:17, Tom Lane wrote:
Mark Kirkwood writes:
It seems that the nub of this issue is that there are conceptually two
types of =, one for datatype specific comparison, and one for optimizer
statistical information calculation. However the system allows only the
first, so if you do
Sunny wrote:
The following bug has been logged online:
Bug reference: 5496
Logged by: Sunny
Email address: goodmeet7...@naver.com
PostgreSQL version: 8.4
Operating system: windows xp
Description:Link does not open though wish to use following site
Details:
Link do
Dean Rasheed writes:
> Hmm. Well it's quite subjective, but IMO it's already more readable
> than JSON regardless of whether or not values are quoted, simply
> because it doesn't have [ ] and { } for lists and maps, which for JSON
> adds significantly to the number of lines in longer plans.
Yeah.
On 9 June 2010 19:50, Robert Haas wrote:
> After thinking about this further, I think I'd still like to take one
> more crack at fixing this without quoting absolutely everything. I
> argued against this feature, but we decided to take it, and it seems
> that one of the major arguments that is be
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
>> than JSON regardless of whether or not values are quoted, simply
>> because it doesn't have [ ] and { } for lists and maps, which for JSON
>> adds signi
Thanks to EveryBody! =)
---
"Seja em você a mudança que quer para o mundo."
Mahatma Gandhi
"A mente que se abre a uma nova idéia jamais voltará ao seu tamanho
original."
Albert Einstein
JOwEL Henrique
(82) 8830-2627
2010/6/9
"Martin Edlman" wrote:
> ERROR: insert or update on table "device" violates foreign key
> constraint "device_parent_id_fkey"
> DETAIL: Key (parent_id)=(19947) is not present in table "device".
>
> But the record is there, it was inserted into net.computer so it's
> selectable from net.device
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 11:14 AM, Tom Lane wrote:
>>
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 11:14 AM, Tom Lane wrote:
>>
On 9 June 2010 14:14, Robert Haas wrote:
> 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
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? Surely we can restrict EXPLAIN's set of key names to
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? Surely we can restrict EXPLAIN's set of key names to be safe.
>>
>>> It seems to me that it would be easy for a
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 patch to break this
>> by accident.
>
> Re
On 9 June 2010 17:25, 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 patch to break this
>> by accident.
>
> Really? What
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 patch to break this
> by accident.
Really? What likely key names would be in need of quoting? I
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 out entirely than do that.
>
> I'd be on board
Dean Rasheed wrote:
> So that just leaves this sort of thing:
>
> explain (format yaml) select * from foo as "123";
What about other quoted identifiers? If I recall correctly, a
quoted identifier can contain *any* characters (although a quote
must be represented as two adjacent quotes).
te
On 9 June 2010 16:05, Robert Haas wrote:
> 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 revie
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 out entirely than do that.
I'd be on board with that too ;-)
> Dean's
> proposal was based on the idea
Robert Haas writes:
> On Wed, Jun 9, 2010 at 1:14 AM, Tom Lane wrote:
>> Yes, that was considered and rejected, IIRC. What is your definition
>> of equality for xml?
> I'd vote for !memcmp().
Surely not. xml is not text.
regards, tom lane
--
Sent via pgsql-bugs mail
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 review, it appears to me that this change is pretty much
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 review, it appears to me that this change is pretty much
> required, because otherwise a string like 0xa won't be quo
On Wed, Jun 9, 2010 at 3:57 PM, Robert Haas wrote:
> I'm suggesting that you prompt for that separately, as shown in the
> above pseudocode. It seems to me that conflating the postgres user
> account password with the database superuser password is confusing...
> IJWH, of course.
As I said in a
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 (${serviceaccount}). If the service account
>> already exists in Windows, you must enter the curre
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 (${serviceaccount}). If the service accoun
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 equality for xml?
I'd vote for !memcmp().
T
On Wed, Jun 9, 2010 at 6:09 AM, Dave Page wrote:
> Please provide a password for the database superuser (${superaccount})
> and service account (${serviceaccount}). If the service account
> already exists in Windows, you must enter the current password for the
> account. If the account does not ex
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?
>> I guess we could do this by (a) conditionalizing the YAML case in
>> ExplainProperty() in the same way that the JSON case is currently
>> conditionalized,
"Martin Edlman" writes:
> [ FK doesn't see a key that is present in a child table ]
That's how FK checks work, see the "Caveats" section at the bottom of
http://www.postgresql.org/docs/8.4/static/ddl-inherit.html
regards, tom lane
--
Sent via pgsql-bugs mailing list (pg
Mark Kirkwood writes:
> It seems that the nub of this issue is that there are conceptually two
> types of =, one for datatype specific comparison, and one for optimizer
> statistical information calculation. However the system allows only the
> first, so if you don't (or can't) have one then yo
On Wed, Jun 9, 2010 at 2:03 PM, Craig Ringer
wrote:
> On 09/06/10 18:09, Dave Page wrote:
>
>> I'm unconvinced that the extra complexity involved in checking the
>> existence of the service account to tweak the message is worthwhile. I
>> don't think it buys us extra simplicity that would suddenly
On 09/06/10 18:09, Dave Page wrote:
> I'm unconvinced that the extra complexity involved in checking the
> existence of the service account to tweak the message is worthwhile. I
> don't think it buys us extra simplicity that would suddenly make
> people understand.
In the end, you know this much
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 has difficulty parsing the
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 has difficulty parsing the output, and you'd have to
write a pretty perverse query to hit
On 9 June 2010 12:32, Robert Haas wrote:
> 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 repo
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 please test. I am
definitely not an
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 please test. I am
>>> definitely not an expert on YAML.
>>>
>>
>> I'm not an expert on YAML either, bu
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 think this works (at
> least it breaks a
On Wed, Jun 9, 2010 at 10:03 AM, Craig Ringer
wrote:
> - During the install, test for the existence of a 'postgres' user
> account before displaying the password prompt panel of the installer
> "wizard".
>
> - If such an account does not exist, display the existing UI password
> prompt ui with sim
On 09/06/10 17:26, Sachin Srivastava wrote:
> If a user has admin rights, he can anytime change the password for an
> existing 'postgres' user account in case he doesn't remember the
> password anymore.
... but people clearly don't know how, given the frequency of questions
about this on the list
On 6/9/10 2:33 PM, Craig Ringer wrote:
On 09/06/10 16:29, Dave Page wrote:
On Wed, Jun 9, 2010 at 8:56 AM, Craig Ringer
wrote:
Only because the PostgreSQL system user account password is coupled to
the account of the "postgres" user in the PostgreSQL database cluster
(right?). I'm
On 09/06/10 16:29, Dave Page wrote:
> On Wed, Jun 9, 2010 at 8:56 AM, Craig Ringer
> wrote:
>
>> Only because the PostgreSQL system user account password is coupled to
>> the account of the "postgres" user in the PostgreSQL database cluster
>> (right?). I'm not at a Windows box right now so I can
On Wed, Jun 9, 2010 at 8:56 AM, Craig Ringer
wrote:
> Only because the PostgreSQL system user account password is coupled to
> the account of the "postgres" user in the PostgreSQL database cluster
> (right?). I'm not at a Windows box right now so I can't test to see if
> altering the Pg role's pa
The following bug has been logged online:
Bug reference: 5495
Logged by: Martin Edlman
Email address: edl...@fortech.cz
PostgreSQL version: 8.4.4
Operating system: Scientific Linux 5.5 (RHEL)
Description:RI/FK on self and inherited table
Details:
I have a table
net
On 09/06/10 15:47, Dave Page wrote:
> On Wed, Jun 9, 2010 at 4:58 AM, Craig Ringer
> wrote:
>
>> Really, the installer on Windows needs to stash the password in an
>> admin-only-readable registry key, read it from there on install, and test to
>> make sure it works. If it does, Pg need not even b
On 9 June 2010 07:58, Dean Rasheed wrote:
> I prefer my patch - but then I suppose I would say that :-)
>
Seriously though, I can think of a number of good arguments in favour
of the "quote all string values unconditionally" approach:
- It's the simplest, least obtrusive fix to our code.
- It's
On Wed, Jun 9, 2010 at 4:58 AM, Craig Ringer
wrote:
> Really, the installer on Windows needs to stash the password in an
> admin-only-readable registry key, read it from there on install, and test to
> make sure it works. If it does, Pg need not even bother the user with the
> account password at
59 matches
Mail list logo
