[BUGS] BUG #4047: case preserve for columns
The following bug has been logged online:
Bug reference: 4047
Logged by: Eugen Konkov
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3
Operating system: Windows XP
Description:case preserve for columns
Details:
1)
SELECT Id FROM MYTABLE;
$sth= fetchall_hashref()
expected: $sth->[i]{Id}
actual: $sth->[i]{id}
2)
SELECT "Id" as ID FROM MYTABLE;
$sth= fetchall_hashref()
expected: $sth->[i]{ID}
actual: $sth->[i]{id}
How ask postgre preserve column names as I query them?
This is a VERY, VERI BIG issue if I need quote all those as:
a) SELECT "Id" FROM MYTABLE;
b) SELECT "Id" as "ID" FROM MYTABLE;
Because of I need by hand quote of 100K queries
But very difficult will be to deal with dinamically generated queries.
Father more "Id" mysql count as string and not field name. So ported to
PostgreSQL queries is not compatible back with MySQL =(
Is there any workaround other then quoting to get working 1) and 2) as
expected?
thanks
PS. other discussion:
http://www.issociate.de/board/post/10327/Case_insensitivity_in_column_and_ta
ble_names.html
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4047: case preserve for columns
Eugen Konkov wrote: Is there any workaround other then quoting to get working 1) and 2) as expected? The SQL standard actually says everything not quoted should be upshifted to upper case. PostgreSQL opted for lower case a long time ago and has stuck with this for legacy. If your "100K lines of SQL" are autogenerated, why not have the autogenerator quote everything thats supposed to be case specific, alleviating any such problems ? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4047: case preserve for columns
It is have no any matter to me if it is upshifted or lowershifted on server sidethe standard does not specify that output of queries MUST be lowershifted/upshifted.why you do this?- Original Message - From: "John R Pierce" <[EMAIL PROTECTED]> To: "Eugen Konkov" <[EMAIL PROTECTED]> Cc: Sent: Friday, March 21, 2008 5:09 PM Subject: Re: [BUGS] BUG #4047: case preserve for columns Eugen Konkov wrote: Is there any workaround other then quoting to get working 1) and 2) as expected? The SQL standard actually says everything not quoted should be upshifted to upper case. PostgreSQL opted for lower case a long time ago and has stuck with this for legacy. If your "100K lines of SQL" are autogenerated, why not have the autogenerator quote everything thats supposed to be case specific, alleviating any such problems ? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4047: case preserve for columns
It is have no any matter to me if it is upshifted or lowershifted on server sidethe standard does not specify that output of queries MUST be lowershifted/upshifted.why you do this? http://archives.postgresql.org/pgsql-hackers/2006-10/msg01527.php - Original Message - From: "John R Pierce" <[EMAIL PROTECTED]> To: "Eugen Konkov" <[EMAIL PROTECTED]> Cc: Sent: Friday, March 21, 2008 5:09 PM Subject: Re: [BUGS] BUG #4047: case preserve for columns Eugen Konkov wrote: Is there any workaround other then quoting to get working 1) and 2) as expected? The SQL standard actually says everything not quoted should be upshifted to upper case. PostgreSQL opted for lower case a long time ago and has stuck with this for legacy. If your "100K lines of SQL" are autogenerated, why not have the autogenerator quote everything thats supposed to be case specific, alleviating any such problems ? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] subscribe
-- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4047: case preserve for columns
<[EMAIL PROTECTED]> writes: > It is have no any matter to me if it is upshifted or lowershifted on server > sidethe standard does not specify that output of queries MUST be > lowershifted/upshifted. Yes it does. I quote SQL92 section 5.2 syntax rule 10: The of a is equivalent to an in which every letter that is a lower- case letter is replaced by the equivalent upper-case letter or letters. This treatment includes determination of equiva- lence, representation in the Information and Definition Schemas, representation in the diagnostics area, and similar uses. In particular "representation in the diagnostics area" would include the case of column headings being returned to the client. If you don't want case folding to happen, you need to use a quoted identifier. In the example you showed, SELECT "Id" AS ID, ... it would have been sufficient to leave off the AS clause. 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
Re: [BUGS] BUG #4047: case preserve for columns
SELECT "Id" AS ID and this will return 'id' instead of 'ID' may be is there server configurations variable to be case sensitive? or return case preserved field names? or may be I compile manually PostgreSQL to do that? Because typing SELECT "Id" AS "ID" instead of SELECT ID is boring else more your variant is less readable If there no any way to migrate to PostgreSQL without changes application it seems not good database because of it will too expensive for us to migrate to ((( - Original Message - From: "Tom Lane" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "John R Pierce" <[EMAIL PROTECTED]>; Sent: Friday, March 21, 2008 6:43 PM Subject: Re: [BUGS] BUG #4047: case preserve for columns <[EMAIL PROTECTED]> writes: It is have no any matter to me if it is upshifted or lowershifted on server sidethe standard does not specify that output of queries MUST be lowershifted/upshifted. Yes it does. I quote SQL92 section 5.2 syntax rule 10: The of a is equivalent to an in which every letter that is a lower- case letter is replaced by the equivalent upper-case letter or letters. This treatment includes determination of equiva- lence, representation in the Information and Definition Schemas, representation in the diagnostics area, and similar uses. In particular "representation in the diagnostics area" would include the case of column headings being returned to the client. If you don't want case folding to happen, you need to use a quoted identifier. In the example you showed, SELECT "Id" AS ID, ... it would have been sufficient to leave off the AS clause. 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
[BUGS] BUG #4048: Can't install pltcl
The following bug has been logged online: Bug reference: 4048 Logged by: IP Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.0 Operating system: Windows XP PL SP2 Description:Can't install pltcl Details: -- Executing query: CREATE LANGUAGE plpythonu; Query returned successfully with no result in 31 ms. -- Executing query: CREATE LANGUAGE pltcl; ERROR: could not load library "C:/Program Files/PostgreSQL/8.3/lib/pltcl.dll": unknown error 126 ** Error ** ERROR: could not load library "C:/Program Files/PostgreSQL/8.3/lib/pltcl.dll": unknown error 126 SQL state: 58P01 == More details: 1. DLL file is in correct path. 2. ActiveState ActiveTcl 8.5.1.0 installed before PostgreSQL. If ActiveTcl is installed after PostgreSQL, same problem occurs. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4048: Can't install pltcl
On Fri, Mar 21, 2008 at 7:00 PM, IP <[EMAIL PROTECTED]> wrote: > > The following bug has been logged online: > > Bug reference: 4048 > Logged by: IP > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.3.0 > Operating system: Windows XP PL SP2 > Description:Can't install pltcl > Details: > > -- Executing query: > CREATE LANGUAGE plpythonu; > > Query returned successfully with no result in 31 ms. > > -- Executing query: > CREATE LANGUAGE pltcl; > > ERROR: could not load library "C:/Program > Files/PostgreSQL/8.3/lib/pltcl.dll": unknown error 126 > > ** Error ** > > ERROR: could not load library "C:/Program > Files/PostgreSQL/8.3/lib/pltcl.dll": unknown error 126 > SQL state: 58P01 > > == > > More details: > 1. DLL file is in correct path. > 2. ActiveState ActiveTcl 8.5.1.0 installed before PostgreSQL. If ActiveTcl > is installed after PostgreSQL, same problem occurs. Binary builds of PostgreSQL for Windows were built against ActiveTcl 8.4.14 -- Dave Page EnterpriseDB UK Ltd: http://www.enterprisedb.com PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Server does not start when log_statement_stats is set to on
I am discarding this thread from the patches queue. We have fixed some
of it so a LOG message is issued for invalid postgresql.conf
combinations. We could do more, but there doesn't seem to be a clear
TODO here.
---
Tom Lane wrote:
> I wrote:
> > The whole idea sounds pretty shaky to me, and definitely not
> > something to change in late beta. LOG we could do now without
> > risking breaking anything.
>
> Poking around a bit more, I notice that there are already some places
> that do it the way I was thinking of, eg in commands/variable.c:
>
> if (!new_tz)
> {
> ereport((source >= PGC_S_INTERACTIVE) ? ERROR : LOG,
> (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> errmsg("unrecognized time zone name: \"%s\"",
> value)));
> return NULL;
> }
>
> However, even this is not really good enough: in the event of a wrong
> entry inserted into postgresql.conf, this coding will result in every
> extant backend emitting the same LOG message at SIGHUP. That's
> annoying. The right way to do it is as illustrated in
> set_config_option(): only the postmaster should log at LOG level,
> everyone else should be down around DEBUG2 (if not lower).
>
> That's getting to be a bit complicated to replicate in N places, though.
> Plus if we ever want to make it work like Alvaro is thinking of, we'd
> have to go back and change all those places again. So I propose
> inventing a function
>
> int guc_complaint_level(GucSource source)
>
> that encapsulates this logic. The correct coding for specialized
> error messages in assign-hook routines would then be like
>
> if (!new_tz)
> {
> ereport(guc_complaint_level(source),
> (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> errmsg("unrecognized time zone name: \"%s\"",
> value)));
> return NULL;
> }
>
> giving us only one place to change to alter this logic.
>
> Comments, objections?
>
> regards, tom lane
>
> ---(end of broadcast)---
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>choose an index scan if your joining column's datatypes do not
>match
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #3822: Nonstandard precedence for comparison operators
Added to TODO: * Fix inconsistent precedence of =, >, and < compared to <>, >=, and <= http://archives.postgresql.org/pgsql-bugs/2007-12/msg00145.php --- Pedro Gimeno wrote: > Tom Lane wrote: > > > "Kevin Grittner" <[EMAIL PROTECTED]> writes: > >> That said, bringing PostgreSQL into compliance with the standard > >> would undoubtedly break some people's existing applications. > > I wonder how that compares to broken queries while migrating databases > from other systems. I'd bet there are more of the latter. We ran into > that while running a query like: SELECT ... WHERE column <> > another_column || 'literal';, variants of which I think can be > relatively common compared to e.g. applications that build a boolean > array using expr1 <> expr2 || boolean_value. > > > The spec seems to barely have a notion of operator precedence at all --- > > The precedence is given by the parse tree and is well defined. Perhaps > it may vary for a given operator depending on the context but it's > clearly different to the one PostgreSQL is using in the examples I gave. > > > for example, all the variants of are at the same precedence > > level, and if I'm reading it right they actively disallow ambiguous > > cases by requiring parentheses; note the way that > > is defined. This entire arrangement breaks down as soon as you consider > > user-defined operators that yield boolean results. So I'm not > > particularly excited about the idea of slavish compliance with the spec > > in this area. > > Note that we considered PostgreSQL precisely because of its high > standards compliance and this problem has been a bit disappointing, even > more given that I looked for information on what nonstandard bits did > PostgreSQL have and didn't see this. > > In the case of user defined operators I'd expect them to have a fixed > precedence regardless of the semantics and that can be different > depending on the operator. > > > Given that it's been this way for ten years and no one has complained > > before, I'm disinclined to change it, and even more disinclined to > > invest the effort that would be involved in letting the behavior vary > > at runtime. > > It has often happened that a new version has caused the need of porting > code, that's not new. Users will very likely appreciate compliance with > the standard even with the hassle of porting the applications, specially > when the fixes, if they're necessary, can easily be made backwards > compatible by using parentheses. For that reason I don't think a runtime > selection of behaviour would be neecessary in this case. > > -- Pedro Gimeno > > > ---(end of broadcast)--- > TIP 1: if posting/reading through Usenet, please send an appropriate >subscribe-nomail command to [EMAIL PROTECTED] so that your >message can get through to the mailing list cleanly -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #3833: Index remains when table is dropped
The comment I have from Tom Lane on this patch is: band-aid solution to just one aspect of problem ... so I am afraid I am going to have to reject it. Sorry. --- Mark Kirkwood wrote: > I encountered this bug recently - and thought I'd have a try at seeing > what might fix it. > > Taking an exclusive lock on the to-be-dropped table immediately (i.e in > RemoveRel) seems to be enough to prevent the drop starting while an > index is being created in another session. So it "fixes" the issue - > possible objections that I can think of are: > > 1/ Not a general solution to multi session dependent drop/create of > objects other than tables (unless we do 2/) > 2/ Using this approach in all object dropping code may result in > deadlocks (but is this worse than dangling/mangled objects?) > > Now, I'm conscious that there could be other show stopper reasons for > *not* doing this that I have not thought of, but figured I'd post in > case the idea was useful. Thoughts? > > Cheers > > Mark [ text/x-patch is unsupported, treating like TEXT/PLAIN ] > *** src/backend/commands/tablecmds.c.orig Wed Jan 2 13:58:05 2008 > --- src/backend/commands/tablecmds.c Wed Jan 2 13:46:43 2008 > *** > *** 514,519 > --- 514,522 > object.objectId = relOid; > object.objectSubId = 0; > > + //Try a lock here! > + LockRelationOid(relOid, ExclusiveLock); > + > performDeletion(&object, behavior); > } > > > ---(end of broadcast)--- > TIP 1: if posting/reading through Usenet, please send an appropriate >subscribe-nomail command to [EMAIL PROTECTED] so that your >message can get through to the mailing list cleanly -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
