- 12 8月, 1998 4 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
functions btrim() ltrim() and rtrim(). The error was that the character after the set was included in the tests (ptr2 pointed to the character after the vardata part of set if no match found, so comparing *ptr or *end against *ptr2 MAY match -> strip). Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) #
-
由 Bruce Momjian 提交于
to understand cursors with variables. Michael
-
由 Bruce Momjian 提交于
-
- 11 8月, 1998 5 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
- 10 8月, 1998 5 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
- 09 8月, 1998 3 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
The attached patch implements some changes that were discussed a couple weeks ago on the hackers and interfaces lists: 1. When the backend sends a NOTICE message and closes the connection (typically, because it was told to by the postmaster after another backend coredumped), libpq will now print the notice and close the connection cleanly. Formerly, the frontend app would usually terminate ungracefully due to a SIGPIPE. (I am not sure if 6.3.2 behaved that way, but the current cvs sources do...) 2. libpq's various printouts to stderr are now fed through a single "notice processor" routine, which can be overridden by the application to direct notices someplace else. This should ease porting libpq to Windows. I also noticed and fixed a problem in PQprint: when sending output to a pager subprocess, it would disable SIGPIPE in case the pager terminates early (this is good) --- but afterwards it reset SIGPIPE to SIG_DFL, rather than restoring the application's prior setting (bad). regards, tom lane
-
- 07 8月, 1998 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 06 8月, 1998 4 次提交
-
-
由 Bruce Momjian 提交于
files. Fix sequence creation hack for relkind type.
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
- 05 8月, 1998 6 次提交
-
-
由 Marc G. Fournier 提交于
From: David Hartwig <daybee@bellatlantic.net> I have attached a patch to allow GROUP BY and/or ORDER BY function or expressions. Note worthy items: 1. The expression or function need not be in the target list. Example: SELECT name FROM foo GROUP BY lower(name); 2. Simplified the grammar to use expressions only. 3. Cleaned up earlier patch in this area to make use of existing utility functions. 3. Reduced some of the members in the SortGroupBy parse node. The original data members were redundant with the new expression node. (MUST do a "make clean" now) 4. Added a new parse node "JoinUsing". The JOIN USING clause was overloading this SortGroupBy structure. With the afore mentioned reduction of members, the two clauses lost all their commonality. 5. A bug still exist where, if a function or expression is GROUPed BY, and an aggregate function does not include a attribute from the expression or function, the backend crashes. (or something like that) The bug pre-dates this patch. Example: SELECT lower(a) AS lowcase, count(b) FROM foo GROUP BY lowcase; *** BOOM *** --Also when not in target list SELECT count(b) FROM foo GROUP BY lower(a); *** BOOM AGAIN ***
-
由 Marc G. Fournier 提交于
From: Dr. Michael Meskes <meskes@online-club.de> So this should finally get cursors working. There was an ugly bug in it.
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
it is now only mergejoin.
-
- 04 8月, 1998 4 次提交
-
-
由 Bruce Momjian 提交于
the postmaster log file.
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
Thanks for Vadim for fixes.
-
- 03 8月, 1998 2 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
- 02 8月, 1998 6 次提交
-
-
由 Thomas G. Lockhart 提交于
There are three or four cases in transformSortClause() and I had fixed only one case for UNION. A second case is now fixed, in the same way; I assigned INT4OID to the column type for the "won't actually happen" sort. Didn't want to skip the code entirely, since the backend needs to _try_ a sort to get the NULLs right. I'm not certain under what circumstances the other cases are invoked and these are not yet fixed up, though perhaps they don't need to be...
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-