The following bug has been logged online:
Bug reference: 5246
Logged by: Chris Travers
Email address: chris.trav...@gmail.com
PostgreSQL version: 8.1.18
Operating system: Fedora Linux 12
Description:Misleading/inconsistent SQLSTATE behavior
Details:
Hi all;
I am
On Wed, Dec 16, 2009 at 12:35 PM, Kevin Grittner
wrote:
> "Chris Travers" wrote:
>
>> I am noticing that that a failed database connection results in an
>> unusable SQLSTATE in libpq, and a very different SQLSTATE than the
>> backend registers.
>
> Wel
trying again. Sorry for the duplicate.
On Wed, Dec 16, 2009 at 1:12 PM, Tom Lane wrote:
> "Chris Travers" writes:
>> I am noticing that that a failed database connection results in an unusable
>> SQLSTATE in libpq, and a very different SQLSTATE than the backend
>&
On Wed, Dec 16, 2009 at 1:39 PM, Tom Lane wrote:
> Chris Travers writes:
>> trying again. Sorry for the duplicate.
>> On Wed, Dec 16, 2009 at 1:12 PM, Tom Lane wrote:
>>> Exactly what "frontend" are you talking about here? Because what this
>>> sou
ppy to try to
write a patch but you probably don't want my C code in your library.)
Best Wishes,
Chris Travers
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Just to be clear (before I consider attempting a patch maybe I can
hand off to someone else to double-check)...
On Wed, Dec 16, 2009 at 5:31 PM, Tom Lane wrote:
> Yeah. The problem is that the only infrastructure libpq has for returning
> individual error message fields (like the SQLSTATE) is a
On Wed, Dec 16, 2009 at 7:07 PM, Tom Lane wrote:
> Chris Travers writes:
>> It looks like this could be added without a disruption to programmer
>> interfaces, but it seems like any major change in this area would
>> create binary compatibility issues (i.e. requir
ared to work in pre-8.3 but may
have done the wrong thing. Definitely quote your literals.
Best Wishes,
Chris Travers
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ed is that the old way simply didn't work for
> any significant use of the dependency info. Just ignoring the
> dependencies, as your patch effectively proposes, is going to lead to
> restore failures or worse.
Just to clarify, the only part that would not be supported would be
the paral
QL problem, and it certainly isn't a Pg
bug. It has to do with changes to the Readline library and the way
linking works on Linux systems.
In general, the word of advice is that unless you know what you are
doing, don't try this at home.
Best Wishes,
Chris Travers
--
Sent via pgsql-bugs
; SELECT col1 FROM myTABLE
>
> SELECT Col1 FROM myTable
>
> please, may you help ?
I thought PgSQL was case insensitive by default and that both those
would be executed as:
SELECT col1 FROM mytable;
If you are seeing otherwise in the manual, can you provide a section?
Best Wishes,
On Wed, Feb 3, 2010 at 11:30 AM, Robert Haas wrote:
> Quoting an identifier also makes it case-sensitive, whereas unquoted
> names are always folded to lower case. For example, the identifiers
> FOO, foo, and "foo" are considered the same by PostgreSQL, but "Foo"
> and "FOO" are different from th
ngrossed in development on the
project) to submit a patch for :-)
Best Wishes,
Chris Travers
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
s
may have improved since I was supporting it but it used to be quite
common that it would cause weird behavior in applications) I
personally think the stack trace is likely to be the best way to test
where the problem is.
Best Wishes,
Chris Travers
--
Sent via pgsql-bugs mailing list (pgs
> If you don't provide more details (test case) it's hard to say if it's a bug
> or not.
Is that a pg-Admin bug report? If so, consider sending it to the
email lists of that project.
Best Wishes,
Chris Travers
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql
Textual representations are not necessarily
consistent.
I guess a better question for Oleg might be:
"Why is it important to you to get this fixed? What are you trying to
do that you can't do without fixing this?"
Best Wishes,
Chris Travers
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
record is greater
than in the row). This seems to be separate from the question of
whether ROW(NULL...) and NULL are the same from a row comparison
viewpoint.
Hope this adds something to the discussion.
Best Wishes,
Chris Travers
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
make
comparisons problematic. In some cases you may need to properly cast
NEW and OLD prior to making comparisons.
Best Wishes,
Chris Travers
--
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, Mar 10, 2010 at 8:20 AM, Robert Haas wrote:
> On Tue, Mar 9, 2010 at 11:02 AM, Tom Lane wrote:
>> We may need to document it, but not like that; it's (a) incorrect and
>> (b) unhelpful to the reader, who is left without any clear idea of what
>> to avoid. I think that the real issue here
7;t sound like a bug, though. Here are a few
questions though to say for sure:
1) This is Windows, right? Which version?
2) You say you "deleted" it. How? What exactly did you do to delete it?
3) Can you try again and copy the full error messages here?
Best Wishes,
Chris Travers
on of this
that would require 8.4 or higher. It might come in handy for
LedgerSMB too.
Best Wishes,
Chris Travers
--
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, Mar 30, 2010 at 12:22 PM, Kevin Grittner
wrote:
> [Did you mean to take this off-list, or was that accidental?]
Accidental.
>
> Chris Travers wrote:
>
>> With due respect, this sort of thing is rather difficult to get
>> right all at once.
>
> Division
On Fri, Apr 2, 2010 at 9:51 AM, Dimitri Fontaine wrote:
>> One could also then store monetary[] arrays for addressing specific
>> denomination storage. I.e. "When closing the till we had 26 pennies,
>> 53 nickles, 12 quarters, 25 $1 bills, 35 $5 bills, 15 $10 bills, and 5
>> $20 bills."
>>
>> Th
- The amount of $CDN currency taken out of the one account, and
> - The amount of $USD currency put into the other account.
>
> You may or may not know both values immediately; as Chris Travers
> observes, there may be some time separation.
>
> It seems like an awfully
this sort of
issue to start on.
Best WIshes,
Chris Travers
begin:vcard
fn:Chris Travers
n:Travers;Chris
email;internet:[EMAIL PROTECTED]
tel;work:509-888-0220
tel;cell:509-630-7794
x-mozilla-html:FALSE
version:2.1
end:vcard
---(end of broadcast)---
differently than UNIX, the process, while straight-forward, is not
intuitive if you have never done it.
Best Wishes,
Chris Travers
On Fri, 2003-12-12 at 03:40, [EMAIL PROTECTED] wrote:
> Hi,
>
>
> I tried installed PostgreSql using CygWin in Windows 2000.
> I got the following error
u can send another email to
the list. You may also want to look at installing the ipc-daemon2 and
postgresql as NT Services.
The other document worth reading is:
/usr/share/doc/Cygwin/postgresql-7.4.README
Best Wishes,
Chris Travers
- Original Message -
From:
Arvind Tiwari
Maybe it would be a good idea to have a manual page called somelint like
libpq-connect and document it there. The other man pages could then
reference it.
Best Wishes,
Chris Travers
---(end of broadcast)---
TIP 3: if posting/reading through
production one).
Best Wishes,
Chris Travers
Metatron Technology Consulting
begin:vcard
fn:Chris Travers
n:Travers;Chris
email;internet:[EMAIL PROTECTED]
x-mozilla-html:FALSE
version:2.1
end:vcard
---(end of broadcast)---
TIP 2: you can get off all
pplication.
Best Wishes,
Chris Travers
Metatron Technology Consulting
---(end of broadcast)---
TIP 6: explain analyze is your friend
work with it.
PostgreSQL is a relational database manager. It stores data for other
programs. It is not adware, spyware, or anything like that. You can
read more about it at http://www.postgresql.org
Best Wishes,
Chris Travers
Metatron Technology Consulting
[EMAIL PROT
the application
(maybe in the function that connects to the DB?)
Best Wishes
Chris Travers
Metatron Technology Consulting
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
participating in/testing/contributing to such
a project?
Best Wishes,
Chris Travers
Metatron Technology Consulting
Tony Marston
http://www.tonymarston.net
-Original Message-
From: Jim C. Nasby [mailto:[EMAIL PROTECTED]
Sent: 10 October 2005 18:19
To: [EMAIL PROTECTED]
Cc: Bruce
Just adding my voice to the "fix it" camp. Is there any reason the
table scans in this sort of thing cannot be independently planned?
Best Wishes,
Chris Travers
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.post
mission-critical, I think it is a good practice to
do what the Pg developers do and avoid making unnecessary changes
within a stable release. This means that some "bugs" should be
treated as "features" where the behavior is longstanding, a workaround
is possible, and the fix
table | postgres | sql | SELECT * FROM
account_heading order b
y accno; | Returns a list of all account headings, currently ordered
by account
number.+
| | |
|
|| | |
|
On Wed, Aug 22, 2012 at 8:04 AM, Tom Lane wrote:
> Chris Travers writes:
>> It's when we add group by that things appear broken. Note it starts
>> returning 196 (14 x 14) records, which suggests a cross join against
>> itself.
>
>> mtech_test=# explain an
Hi;
I figured I would report this as well, primarily because people
getting into table inheritance may try to use this to solve the set
exclusion problem (i.e. partly required to prevent duplicate key
values in an inheritance tree). I see this as minor because I don't
see a lot of people using th
On Fri, Aug 24, 2012 at 3:52 AM, Amit Kapila wrote:
> From: pgsql-bugs-ow...@postgresql.org
> [mailto:pgsql-bugs-ow...@postgresql.org] On Behalf Of Tom Lane
> Sent: Friday, August 24, 2012 10:33 AM
> Chris Travers writes:
>>> My guess is that tableoid is not known when th
ange without notice.
Maybe worth bringing up on the docs list. I don't mind the fact that
behavior is undefined in some cases. However, it might be a good idea to
let people know that they are moving into "we won't commit not to breaking
your app even if you get this to work" territory.
Best Wishes,
Chris Travers
in ALTER TABLE and much more about documenting the chosen
> behavior. I think the reason you're confused by the proposed TODO
> wording is exactly that it uses the phrases "TYPE features" and "TABLE
> features" as if those concepts were defined or documented anywhere.
>
To be honest, having worked with these a bit, I think we need to choose the
behavior before we can document or even implement it.
Best Wishes,
Chris Travers
constraint, you'd probably have to go
> looking around for type_constraints() though.
>
> merlin
>
I suppose this is yet another reason why multiple inheritance is an
absolutely killer feature in PostgreSQL is that currently you *can* model
your data in an equivalent way *and* have check constraints and not null
constraints enforced ;-)
Best Wishes,
Chris Travers
d above.
This is one of those reasons I don't see the backwards-compatibility
reasons so convincing. We can't create some modicum of consistency in
behavior without breaking *something.* I think the big issue is that
nobody has figured out exactly what we want to break.
Best Wishes,
Chris Travers
create a different timeline?
Best Wishes,
Chris Travers
The following bug has been logged on the website:
Bug reference: 8170
Logged by: Chris Travers
Email address: chris.trav...@gmail.com
PostgreSQL version: 9.2.4
Operating system: Debian Linux
Description:
I have a pl/pgsql function which calculates at imestamp and
45 matches
Mail list logo
