Re: [HACKERS] .psqlrc output for \pset commands
Peter Eisentraut wrote: Am Thursday, 17. July 2008 schrieb Bruce Momjian: Anyways the thing that struck me as odd was the messages appearing *before* the header. It seems to me the header should print followed by .psqlrc output followed by normal output. Do you like this better? $ psql test psql (8.4devel) Type help for help. Output format is wrapped. test= The attached patch accomplishes this. The psqlrc file must be read before the welcome message is printed, so that you can disable the welcome message in the psqlrc file. Otherwise we are reopening the whole issue of when and whether to print a welcome message that we had just settled. Oh, yea, sorry. Reverted. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Getting to universal binaries for Darwin
Am Sunday, 20. July 2008 schrieb Tom Lane:
* This disables AC_TRY_RUN tests, of course. The only adverse
consequence I noticed was failure to recognize that
-Wl,-dead_strip_dylibs is applicable, which is marginally annoying but
hardly fatal.
On the whole I still wouldn't trust cross-compiled configure results.
Better to get your prototype pg_config.h from the real deal.
For example, I'm a bit curious on the following aspect. This program should
fail to compile on 32-bit platforms but succeed on 64-bit:
#include stddef.h
struct s { char a; long b; };
int main(int argc, char *argv[])
{
int array[offsetof(struct s, b) - 5];
return 0;
}
What happens if you run gcc -arch i386 -arch ppp64 on it? Does it require
success on both output architectures?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Getting to universal binaries for Darwin
Peter Eisentraut [EMAIL PROTECTED] writes:
For example, I'm a bit curious on the following aspect. This program should
fail to compile on 32-bit platforms but succeed on 64-bit:
#include stddef.h
struct s { char a; long b; };
int main(int argc, char *argv[])
{
int array[offsetof(struct s, b) - 5];
return 0;
}
What happens if you run gcc -arch i386 -arch ppp64 on it? Does it require
success on both output architectures?
Seems so. On a current MacBook Pro:
$ cat test.c
#include stddef.h
struct s { char a; long b; };
int main(int argc, char *argv[])
{
int array[offsetof(struct s, b) - 5];
return 0;
}
$ gcc -c test.c
test.c: In function 'main':
test.c:7: error: size of array 'array' is too large
$ gcc -arch i386 -c test.c
test.c: In function 'main':
test.c:7: error: size of array 'array' is too large
$ gcc -arch x86_64 -c test.c
$ gcc -arch ppc -c test.c
test.c: In function 'main':
test.c:7: error: size of array 'array' is too large
$ gcc -arch ppc64 -c test.c
$ gcc -arch i386 -arch x86_64 -c test.c
test.c: In function 'main':
test.c:7: error: size of array 'array' is too large
lipo: can't figure out the architecture type of:
/var/folders/5M/5MGusdunEbWmuxTsRCYfbk+++TI/-Tmp-//ccfrarXl.out
$ gcc -arch i386 -arch ppc -c test.c
test.c: In function 'main':
test.c:7: error: size of array 'array' is too large
test.c: In function 'main':
test.c:7: error: size of array 'array' is too large
lipo: can't figure out the architecture type of:
/var/folders/5M/5MGusdunEbWmuxTsRCYfbk+++TI/-Tmp-//ccFqrJgr.out
$
This doesn't look amazingly well tested though: what I suspect is
happening is that it runs N instances of the compiler (note multiple
errors in the last case) and then tries to sew their output together
with lipo, whether they succeeded or not. I'll bet the can't figure
out is reflecting not being able to make sense of a zero-length .o
file ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] temp table problem
Tom Lane wrote:
What PG version are you testing? Maybe you need to show a complete
test case, instead of leaving us to guess at details?
I think that example is bogus. Let's forget that one, and look at the
attached script.
The underlying problem is that when we do GetOverrideSearchPath() in
CreateCachedPlan, the memorized search path doesn't include pg_temp, if
the temp namespace wasn't initialized for the backend yet. When we later
need to revalidate the plan, pg_temp still isn't searched, even if it
now exists.
(On 8.3 and CVS HEAD)
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
DROP TABLE IF EXISTS ambiguous_table;
CREATE TABLE ambiguous_table(which text);
INSERT INTO ambiguous_table VALUES ('permanent');
CREATE OR REPLACE FUNCTION ss () RETURNS text LANGUAGE plpgsql AS $$
BEGIN
RETURN which FROM ambiguous_table;
END;
$$;
-- Returns 'permanent'
SELECT ss();
-- Replace the table in 'public' schema with a temp table
DROP TABLE ambiguous_table;
CREATE TEMP TABLE ambiguous_table(which text);
INSERT INTO ambiguous_table VALUES ('temp');
-- Should return 'temp', but fails if pg_temp wasn't initialized
-- before executing the function the first time.
SELECT ss();
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] WITH RECUSIVE patches 0717
This crashes the backend:
WITH RECURSIVE t(n) AS (
VALUES (1)
UNION ALL
SELECT n+1 FROM t WHERE n 5 ORDER BY 1
)
SELECT n FROM t;
apparently because of the ORDER BY 1
Thanks for the report. I think ORDER BY in this case is useless
anyway. ORDER BY affects (VALUES (1) UNION ALL SELECT n+1 FROM t WHERE
n 5). Since this is a recursive query, value for (VALUES (1) UNION
ALL SELECT n+1 FROM t WHERE n 5) will not be determined until the
recursion stops. So the meaning of ORDER BY is vague. If caller wants
to get the sorted result of the recursion, he could always write:
WITH RECURSIVE t(n) AS (
VALUES (1)
UNION ALL
SELECT n+1 FROM t WHERE n 5
)
SELECT n FROM t ORDER BY 1;
Thus I think we should avoid this kind of ORDER BY. Probably we should
avoid LIMIT/OFFSET and FOR UPDATE as well. Included patches add the
checking plus minor error messages clarifications. Also I include new
error cases sql.
( ORDER BY t.n will just error out )
Compiled with:
./configure \
--prefix=${install_dir} \
--with-pgport=${pgport} \
--quiet \
--enable-depend \
--enable-cassert \
--enable-debug \
--with-openssl
hth
Erik Rijkers
-- UNION
WITH RECURSIVE x(n) AS (SELECT 1 UNION SELECT n+1 FROM x)
SELECT * FROM x;
-- INTERSECT
WITH RECURSIVE x(n) AS (SELECT 1 INTERSECT SELECT n+1 FROM x)
SELECT * FROM x;
WITH RECURSIVE x(n) AS (SELECT 1 INTERSECT ALL SELECT n+1 FROM x)
SELECT * FROM x;
-- EXCEPT
WITH RECURSIVE x(n) AS (SELECT 1 EXCEPT SELECT n+1 FROM x)
SELECT * FROM x;
WITH RECURSIVE x(n) AS (SELECT 1 EXCEPT ALL SELECT n+1 FROM x)
SELECT * FROM x;
-- no non-recursive term
WITH RECURSIVE x(n) AS (SELECT n FROM x)
SELECT * FROM x;
-- recursive term in the left hand side
WITH RECURSIVE x(n) AS (SELECT n FROM x UNION ALL SELECT 1)
SELECT * FROM x;
CREATE TEMP TABLE y (a int);
INSERT INTO y SELECT generate_series(1, 10);
-- LEFT JOIN
WITH RECURSIVE x(n) AS (SELECT a FROM y WHERE a = 1 UNION ALL SELECT x.n+1 FROM
y LEFT JOIN x ON x.n = y.a where n 10)
SELECT * FROM x;
-- RIGHT JOIN
WITH RECURSIVE x(n) AS (SELECT a FROM y WHERE a = 1 UNION ALL SELECT x.n+1 FROM
x RIGHT JOIN y ON x.n = y.a where n 10)
SELECT * FROM x;
-- FULL JOIN
WITH RECURSIVE x(n) AS (SELECT a FROM y WHERE a = 1 UNION ALL SELECT x.n+1 FROM
x FULL JOIN y ON x.n = y.a where n 10)
SELECT * FROM x;
-- subquery
WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL SELECT n+1 FROM x
WHERE n IN (SELECT * FROM x))
SELECT * FROM x;
WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL SELECT n+1 FROM x
WHERE n = 1 AND n IN (SELECT * FROM x))
SELECT * FROM x;
-- GROUP BY
WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL SELECT n+1 FROM x GROUP BY n)
SELECT * FROM x;
-- HAVING
WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL SELECT n+1 FROM x HAVING n 10)
SELECT * FROM x;
-- aggregate functions
WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL SELECT count(*) FROM x)
SELECT * FROM x;
WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL SELECT sum(*) FROM x)
SELECT * FROM x;
-- ORDER BY
WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL SELECT n+1 FROM x ORDER BY 1)
SELECT * FROM x;
-- LIMIT/OFFSET
WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL SELECT n+1 FROM x LIMIT 10 OFFSET 1)
SELECT * FROM x;
-- FOR UPDATE
WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL SELECT n+1 FROM x FOR UPDATE)
SELECT * FROM x;
recursive_query.patch.gz
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] temp table problem
Heikki Linnakangas [EMAIL PROTECTED] writes: The underlying problem is that when we do GetOverrideSearchPath() in CreateCachedPlan, the memorized search path doesn't include pg_temp, if the temp namespace wasn't initialized for the backend yet. When we later need to revalidate the plan, pg_temp still isn't searched, even if it now exists. So what's the problem? The cached plan couldn't have referred to a temp table. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] WITH RECUSIVE patches 0717
Tatsuo Ishii [EMAIL PROTECTED] writes: Thus I think we should avoid this kind of ORDER BY. Probably we should avoid LIMIT/OFFSET and FOR UPDATE as well. What of index-optimized SELECT max(...) ? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] CommitFest dragging?
Folks, It's been 3 weeks since the start of the commitfest, and less than half the patches have been committed or sent back. We seem to be stalled. What's going on? Looking at the wiki, I see some issues: Robert Lor, Jaime Casanova, Mark Woodward, Heikki Linnakangas Zoltan Boszormenyi and Greg Stark apparently haven't responded to issues raised by their reviewers. David Fetter, Stephen Frost, Greg Stark, Thomas Lee, Bruce Momjian, Peter Eisentraut, Pavan Deolasee, Martin Zaun and Simon Riggs are all reviewing patches and need to report back, either sending back the patch or finishing it. And there's four patches which aren't even being reviewed because most of the reviewers are stalled (not) reviewing other patches. So, what do we need to do to get this moving? --Josh -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] CommitFest dragging?
On Sun, 2008-07-20 at 10:17 -0700, Josh Berkus wrote: Folks, It's been 3 weeks since the start of the commitfest, and less than half the patches have been committed or sent back. We seem to be stalled. What's going on? So, what do we need to do to get this moving? Let's not forget that it is the middle of summer. As I recall that was the whole reason to try and push 8.2 to a late spring release :P (which failed of course) but my point is, people are low on cycles. Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] CommitFest dragging?
Joshua D. Drake [EMAIL PROTECTED] writes: On Sun, 2008-07-20 at 10:17 -0700, Josh Berkus wrote: It's been 3 weeks since the start of the commitfest, and less than half the patches have been committed or sent back. We seem to be stalled. Let's not forget that it is the middle of summer. As I recall that was the whole reason to try and push 8.2 to a late spring release :P (which failed of course) but my point is, people are low on cycles. Sure, but the folks who volunteered to be reviewers for this fest presumably expected to have cycles to do that. I agree with Josh B that there's too many patches for which nothing has happened for longer than is reasonable. I don't have a problem with pushing a patch to the next fest if the author is the one who's not answering, but it'd be less than fair to do so when it's the reviewer who's dropped the ball. (At the same time, it should be noted that some of the patches seem to be getting review activity that's not reflected on the wiki page. A lot of people seem to have poked at the WITH RECURSIVE patch in particular.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] CommitFest dragging?
Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: On Sun, 2008-07-20 at 10:17 -0700, Josh Berkus wrote: It's been 3 weeks since the start of the commitfest, and less than half the patches have been committed or sent back. We seem to be stalled. libpq object hooks, now called libpq events, can be pushed back to the september commitfest. We would love to get it reviewed now but we are deeply involved in a company project and the commitfest seems to be a bit behind. The two combined make for a good push back candidate. Do we need to add this patch to the sept commitfest? How would we remove it from the current one? -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] CommitFest dragging?
Andrew, Do we need to add this patch to the sept commitfest? How would we remove it from the current one? Done. --Josh -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] WITH RECUSIVE patches 0717
Thus I think we should avoid this kind of ORDER BY. Probably we should avoid LIMIT/OFFSET and FOR UPDATE as well. What of index-optimized SELECT max(...) ? Aggregate functions in a recursive term is prohibited by the standard. For example, WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL SELECT max(n) FROM x) SELECT * FROM x; produces an error. -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] WITH RECUSIVE patches 0717
On Mon, Jul 21, 2008 at 08:19:35AM +0900, Tatsuo Ishii wrote: Thus I think we should avoid this kind of ORDER BY. Probably we should avoid LIMIT/OFFSET and FOR UPDATE as well. What of index-optimized SELECT max(...) ? Aggregate functions in a recursive term is prohibited by the standard. For example, WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL SELECT max(n) FROM x) SELECT * FROM x; produces an error. On the other side of UNION ALL, it's OK, right? For example, WITH RECURSIVE x(n) AS ( SELECT max(i) FROM t UNION ALL SELECT n+1 FROM x WHERE n 20 ) Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] WITH RECUSIVE patches 0717
On Mon, Jul 21, 2008 at 08:19:35AM +0900, Tatsuo Ishii wrote: Thus I think we should avoid this kind of ORDER BY. Probably we should avoid LIMIT/OFFSET and FOR UPDATE as well. What of index-optimized SELECT max(...) ? Aggregate functions in a recursive term is prohibited by the standard. For example, WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL SELECT max(n) FROM x) SELECT * FROM x; produces an error. On the other side of UNION ALL, it's OK, right? For example, WITH RECURSIVE x(n) AS ( SELECT max(i) FROM t UNION ALL SELECT n+1 FROM x WHERE n 20 ) Yes, aggregate functions in the non-recursive term is allowed by the standard. -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [WIP] collation support revisited (phase 1)
I was trying to sort out the problem with not creating new catalog for character sets and I came up following ideas. Correct me if my ideas are wrong. Since collation has to have a defined character set I'm suggesting to use already written infrastructure of encodings and to use list of encodings in chklocale.c. Currently databases are not created with specified character set but with specified encoding. I think instead of pointing a record in collation catalog to another record in character set catalog we might use only name (string) of the encoding. So each collation will be set over these encodings set in chklocale.c. Each database will be able to use only collations that are created over same (compatible) encodings regarding encoding_match_list. Each standard collation (SQL standard) will be defined over all possible encodings (hard-coded). Comments? Regards Radek Strnad On Sat, Jul 12, 2008 at 5:17 PM, Tom Lane [EMAIL PROTECTED] wrote: Zdenek Kotala [EMAIL PROTECTED] writes: I think if we support UTF8 encoding, than it make sense to create own charsets, because system locales could have defined collation for that. Say what? I cannot imagine a scenario in which a user-defined encoding would be useful. The amount of infrastructure you need for a new encoding is so large that providing management commands is just silly --- anyone who can create the infrastructure can do the last little bit for themselves. The analogy to index access methods is on point, again. regards, tom lane
[HACKERS] Any reason not to return row_count in cursor of plpgsql?
hi all, I read the code that it seems easy for the cursor in plpgsql to return ROW_COUNT after MOVE LAST etc. The SPI_processed variable already there, but didn't put it into estate structure, any reason for that? thanks and best regards -laser -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] TODO item: Have psql show current values for a sequence
Bruce Momjian [EMAIL PROTECTED] writes: Wow. I adjusted the patch slightly and applied it; the updated version is attached. We have been waiting for this to be done for quite some time. Thanks. Hmm ... I don't think that this patch actually addresses the TODO item. The TODO item seems to have originated here http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/TODO.diff?r1=1.1220;r2=1.1221;f=h in response to this question on pgsql-novice: How can I list all the sequences in the database, with their attributes (such as last_value)? (I'm having a hard time guessing 'seq-name'; the 'A_id_seq' formula did not work.) http://archives.postgresql.org/pgsql-novice/2004-02/msg00148.php This applied-with-little-discussion patch only shows the sequence values if you do a \d on a specific sequence, or \d on a wildcard that happens to include some sequences (and probably a lot of other stuff too, causing the resulting display to be far too long to be useful). My interpretation of the TODO item has always been that we should improve \ds to include all the useful information in a format that requires only one line per sequence. The reason it has remained undone for four years is that that's hard given the existing catalog representation of sequences and the constraints of describe.c's implementation. (I recall at least one failed patch that tried to do this, though I can't find it in the archives right now.) I find the present patch to be pretty useless: it's not a material advance over doing select * from sequence-name. I think it should be reverted and the TODO item reinstated --- perhaps with more detail about what the item really is requesting. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
