Re: [SQL] [OT] SUMMERY Frontend recommendations
SUMMERY Question: > Hey postgresql gurus, > > I was just wondering, what kind of frontend do you recommend in 'bills > (windows...)' environment? > Is it better to use a tool like Qt from trolltech or is it better to use > something like Omnis or Access??? > > What are you opinions ANSWERS: It all depends what you need to do. From using Qt for graphical frontend. I have found the Sql bits to be extremly slow. So the plan is currently to stop using them and use the pqxx drivers. Change is not easy however! (Thats under Linux...) If you need a quick gui try pgaccess and the like. If you want to writea full gui pick you favoute language and there should be some postgres drivers (if all else fails there is always ODBC) somthing like perl or python may be nice and platform independant <> I've always felt there's nowt wrong with Access as a way of building forms/reports etc. ---(end of broadcast)--- TIP 3: 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
Re: [SQL] plpgsql doesn't coerce boolean expressions to boolean
I would suggest to throw a error, or at least a warning. This will FORCE people to program in the correct way. I also thought that 'IF $1 THEN ...' should work ok but giving it a other thought it's indeed stuped to write that way (I'm from the C world...) Ries -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Tom Lane Verzonden: maandag 8 september 2003 17:41 Aan: [EMAIL PROTECTED]; [EMAIL PROTECTED] Onderwerp: [SQL] plpgsql doesn't coerce boolean expressions to boolean Following up this gripe http://archives.postgresql.org/pgsql-sql/2003-09/msg00044.php I've realized that plpgsql just assumes that the test expression of an IF, WHILE, or EXIT statement is a boolean expression. It doesn't take any measures to ensure this is the case or convert the value if it's not the case. This seems pretty bogus to me. However ... with the code as it stands, for pass-by-reference datatypes any nonnull value will appear TRUE, while for pass-by-value datatypes any nonzero value will appear TRUE. I fear that people may actually be depending on these behaviors, particularly the latter one which is pretty reasonable if you're accustomed to C. So while I'd like to throw an error if the argument isn't boolean, I'm afraid of breaking people's function definitions. Here are some possible responses, roughly in order of difficulty to implement: 1. Leave well enough alone (and perhaps document the behavior). 2. Throw an error if the expression doesn't return boolean. 3. Try to convert nonbooleans to boolean using plpgsql's usual method for cross-type coercion, ie run the type's output proc to get a string and feed it to bool's input proc. (This seems unlikely to avoid throwing an error in very many cases, but it'd be the most consistent with other parts of plpgsql.) 4. Use the parser's coerce_to_boolean procedure, so that nonbooleans will be accepted in exactly the same cases where they'd be accepted in a boolean-requiring SQL construct (such as CASE). (By default, none are, so this isn't really different from #2. But people could create casts to boolean to override this behavior in a controlled fashion.) Any opinions about what to do? regards, tom lane ---(end of broadcast)--- TIP 3: 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [SQL] Sorting problem
I think what you actually want is natural sorting. Ries > -Oorspronkelijk bericht- > Van: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Jean-Luc Lachance > Verzonden: woensdag 15 oktober 2003 17:43 > Aan: George A.J > CC: [EMAIL PROTECTED] > Onderwerp: Re: [SQL] Sorting problem > > > You are obviously not using C locale. > If you can't change it for some reason, you can use: > > select * from accounts order by int4( trim( acno, '#')); > > JLL > > "George A.J" wrote: > > > > hi all, > > i am using postgres 7.3.2 .i am converitng a mssql database to > > postgres. > > now i am facing a strange problem. sorting based on a > varchar field is > > not working > > as expected. the non alphanumeric characters are not > sorting based on > > the ascii > > value of them. > > > > i have the following table structure.. > > > > create table accounts > > ( > > AcNo varchar (10), > > Name varchar(100), > > balance numeric(19,4) > > ) > > > > when i used the query select * from accounts order by acno. the > > result is not correct > > > > suppose that the acno field contains values '###1' ,'###2' ,'##10' , > > '#100' > > the sort order in postgres is > > '###1' > > '##10' > > '#100' > > '###2' > > But i want the result as follows > > '###1' > > '###2' > > '##10' > > '#100' > > > > that means the ascii value of # should be considered for sorting.. > > what is the problem. is it the behaviour of postgres. > > do i need to change any configuration. i am using all default > > configurations > > or is it a bug...? > > the problem actually is of < & > operators for varchar. > > > > in a simple comparison > > > > select '###2' < '##10' > > > > returns false but i need true. > > > > is there any solution exist. even if i replaced # with any non > > alphanumeric > > character the result is same.. > > > > pls help > > > > jinu jose > > > > > -- > > Do you Yahoo!? > > The New Yahoo! Shopping - with improved product search > > ---(end of > broadcast)--- > TIP 5: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faqs/FAQ.html > ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
