Re: [HACKERS] Adding column comment to information_schema.columns
Tom Lane wrote: Justin Clift <[EMAIL PROTECTED]> writes: Not sure how worthwhile others will find this small patch (to CVS HEAD), but we found it useful. It adds the column comments to the information_schema.columns view. This question has been touched on before, but I guess it's time to face it fair and square: is it reasonable for an SQL implementation to add implementation-specific columns to an information_schema view? One could certainly argue that the entire point of information_schema is to be *standard*, not more, not less. OTOH I do not know if adding an extra column is likely to break anyone's application. Comments? Well, I suppose it reduces application portability if anyone starts relying on it. ? Regards and best wishes, Justin Clift regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] compile warnings
Joe Conway <[EMAIL PROTECTED]> writes: > In addition to the ecpg warnings mentioned by Tom, I'm also seeing > compile warnings wrt plpython: > make[3]: Entering directory `/opt/src/pgsql-cvs/pgsql-7.5/src/pl/plpython' > gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes > -Wmissing-declarations -fpic -I. -I/usr/include/python2.3 > -I../../../src/include -D_GNU_SOURCE -I/usr/include/et -c -o > plpython.o plpython.c -MMD > In file included from /usr/include/python2.3/Python.h:8, > from plpython.c:58: > /usr/include/python2.3/pyconfig.h:847:1: warning: "_POSIX_C_SOURCE" > redefined > In file included from /usr/include/stdio.h:28, > from ../../../src/include/c.h:60, > from ../../../src/include/postgres.h:48, > from plpython.c:37: > /usr/include/features.h:131:1: warning: this is the location of the > previous definition > ar crs libplpython.a plpython.o I think this must be breakage in your local python installation, not in Postgres. Note the complaint is that /usr/include/python2.3/pyconfig.h disagrees with /usr/include/features.h ... it's not hard to decide who's at fault there. PG could be an accessory to the crime, but AFAICS we've not mucked with include order or predefined symbols for plpython.c lately; so if we broke it, it was awhile ago. This is surely not a "must fix tomorrow" issue, but please look into it when you get back from your road trip. (Where are you going, anyway? 3600 miles is a long way...) 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
Re: [HACKERS] compile warnings
Tom Lane wrote: Joe Conway <[EMAIL PROTECTED]> writes: In file included from /usr/include/python2.3/Python.h:8, from plpython.c:58: /usr/include/python2.3/pyconfig.h:847:1: warning: "_POSIX_C_SOURCE" redefined In file included from /usr/include/stdio.h:28, from ../../../src/include/c.h:60, from ../../../src/include/postgres.h:48, from plpython.c:37: /usr/include/features.h:131:1: warning: this is the location of the previous definition I think this must be breakage in your local python installation, not in Postgres. Note the complaint is that /usr/include/python2.3/pyconfig.h disagrees with /usr/include/features.h ... it's not hard to decide who's at fault there. PG could be an accessory to the crime, but AFAICS we've not mucked with include order or predefined symbols for plpython.c lately; so if we broke it, it was awhile ago. I'm on a relatively new/vanilla fedora core 2 system, so the fault might lie there. This is surely not a "must fix tomorrow" issue, but please look into it when you get back from your road trip. OK, will do. (Where are you going, anyway? 3600 miles is a long way...) San Diego to Mississippi and back. Visit family, attend a wedding, etc. We do this trip every year or two, so I'm used to it by now ;-) Joe ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Adding column comment to information_schema.columns
Not sure how worthwhile others will find this small patch (to CVS HEAD), but we found it useful. It adds the column comments to the information_schema.columns view. Is column comment in the standard? If not, we cannot of course add it... Chris ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] possibly updating techdocs; mysql2pgsql on gborg
hi , I am on a mission to simply keep a starving project off the ground by updating an old mysql->pgsql perl conversion script which does its conversion very differently from the one under contrib/. There is an old link to http://www.rot13.org/~dpavlin/sql.html on techdocs under the section Converting from other Databases to PostgreSQL in a section which was apparently "Last updated 7th September 2002" If anybody still has access to that page, the project has moved to gborg specifically over to http://gborg.postgresql.org/project/mysql2psql/projdisplay.php where a new version of the perl conversion script is located. "Can the link be updated?" The version on gborg has cvs access and multiple developers, and is being maintained bymyself. I would be amazed if nobody else tweaked it in its weak spots. thanks, joe speigle ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Performance with new nested-xacts code
Hi Tom, As requested - although the results are all over the place... :-( One interesting factor in these tests is that the max tps without the new code was 74.7, with the new code, 85.8. This is a Sony Laptop, slow IDE disk, Fedora Core 2 [EMAIL PROTECTED] pgsql-HEAD]$ uname -a Linux localhost.localdomain 2.6.6-1.435 #1 Mon Jun 14 09:09:07 EDT 2004 i686 i686 i386 GNU/Linux ./bin/postmaster -F HTH. Regards, Grant -- PRE NESTED XACTS [EMAIL PROTECTED] pgbench]$ ./pgbench -c 5 -t 1000 bench starting vacuum...end. transaction type: TPC-B (sort of) scaling factor: 10 number of clients: 5 number of transactions per client: 1000 number of transactions actually processed: 5000/5000 tps = 74.632059 (including connections establishing) tps = 74.710309 (excluding connections establishing) [EMAIL PROTECTED] pgbench]$ ./pgbench -c 5 -t 1000 bench starting vacuum...end. transaction type: TPC-B (sort of) scaling factor: 10 number of clients: 5 number of transactions per client: 1000 number of transactions actually processed: 5000/5000 tps = 61.405658 (including connections establishing) tps = 61.471754 (excluding connections establishing) [EMAIL PROTECTED] pgbench]$ ./pgbench -c 5 -t 1000 bench starting vacuum...end. transaction type: TPC-B (sort of) scaling factor: 10 number of clients: 5 number of transactions per client: 1000 number of transactions actually processed: 5000/5000 tps = 59.702545 (including connections establishing) tps = 59.754499 (excluding connections establishing) [EMAIL PROTECTED] pgbench]$ ./pgbench -c 5 -t 1000 bench starting vacuum...end. transaction type: TPC-B (sort of) scaling factor: 10 number of clients: 5 number of transactions per client: 1000 number of transactions actually processed: 5000/5000 tps = 54.531685 (including connections establishing) tps = 54.584432 (excluding connections establishing) -- POST NESTED XACTS [EMAIL PROTECTED] pgbench]$ ./pgbench -c 5 -t 1000 bench starting vacuum...end. transaction type: TPC-B (sort of) scaling factor: 10 number of clients: 5 number of transactions per client: 1000 number of transactions actually processed: 5000/5000 tps = 72.656915 (including connections establishing) tps = 72.732723 (excluding connections establishing) [EMAIL PROTECTED] pgbench]$ ./pgbench -c 5 -t 1000 bench starting vacuum...end. transaction type: TPC-B (sort of) scaling factor: 10 number of clients: 5 number of transactions per client: 1000 number of transactions actually processed: 5000/5000 tps = 85.687383 (including connections establishing) tps = 85.822281 (excluding connections establishing) [EMAIL PROTECTED] pgbench]$ ./pgbench -c 5 -t 1000 bench starting vacuum...end. transaction type: TPC-B (sort of) scaling factor: 10 number of clients: 5 number of transactions per client: 1000 number of transactions actually processed: 5000/5000 tps = 59.479127 (including connections establishing) tps = 59.540478 (excluding connections establishing) [EMAIL PROTECTED] pgbench]$ ./pgbench -c 5 -t 1000 bench starting vacuum...end. transaction type: TPC-B (sort of) scaling factor: 10 number of clients: 5 number of transactions per client: 1000 number of transactions actually processed: 5000/5000 tps = 51.675145 (including connections establishing) tps = 51.715526 (excluding connections establishing) Tom Lane wrote: [snip] Can anyone else reproduce these results? The test case I'm using is pgbench -i -s 10 bench followed by repeated pgbench -c 5 -t 1000 bench I've built PG with --enable-debug and --enable-cassert, and am running with -F (fsync off) but otherwise absolutely factory-stock postgresql.conf. The hardware is a not-so-new-anymore Dell P4 with run-of-the-mill IDE disk drive, running RHL 8.0. Obviously none of this is tuned at all, but the question is why did CVS tip get faster when it should by rights be slower. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Performance with new nested-xacts code
On Thu, Jul 01, 2004 at 12:21:55AM -0400, Tom Lane wrote: > I was all set to launch into a diatribe about the half dozen performance > issues I think we *must* fix in the new nested-transactions code, I completely agree, of course. > This brought me up short. I sure as heck do not see anything in that > patch that would represent a performance gain over before, especially > not in the very vanilla-flavor cases exercised by pgbench. Do you see > an explanation? I'm a bit worried that we've managed to dike out some > essential operation or other... Nope, nothing; in fact, I think the only thing that changed in the normal (no subxacts) code path are the tqual.c tests, and those ought to be more expensive than before, not less ... The only thing that changed somewhat is the new GUC code you wrote, but I doubt that could account for a 10% performance increase. > Can anyone else reproduce these results? The test case I'm using is > pgbench -i -s 10 bench > followed by repeated > pgbench -c 5 -t 1000 bench I measure the same in 7 runs: Yesterday Today 241.37 243.02 215.3 228.58 235.13 225.57 194.72 253.23 215.98 272.14 239.15 262.35 220.17 249.42 Min 194.72 225.57 Max 241.37 272.14 Avg 223.12 247.76 -- Alvaro Herrera () "Por suerte hoy explotó el califont porque si no me habría muerto de aburrido" (Papelucho) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Adding column comment to information_schema.columns
On Thu, 1 Jul 2004, Justin Clift wrote: > but we found it useful. It adds the column comments to the > information_schema.columns view. Doesn't the specification say exactly what columns should exist? Lots of things in the old system tables are not visible in the information_schema because of this. Not that I think a comment column would hurt, but anyway. -- /Dennis Björklund ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Performance with new nested-xacts code
I was all set to launch into a diatribe about the half dozen performance issues I think we *must* fix in the new nested-transactions code, and thought I'd back it up by citing some pgbench numbers. So I ran pgbench runs using yesterday's CVS tip and current. I had to fix a small memory leak before I could get through pgbench -i at all :-(, but after that I found that today's tip seems a good 10% faster than yesterday's. This brought me up short. I sure as heck do not see anything in that patch that would represent a performance gain over before, especially not in the very vanilla-flavor cases exercised by pgbench. Do you see an explanation? I'm a bit worried that we've managed to dike out some essential operation or other... Can anyone else reproduce these results? The test case I'm using is pgbench -i -s 10 bench followed by repeated pgbench -c 5 -t 1000 bench I've built PG with --enable-debug and --enable-cassert, and am running with -F (fsync off) but otherwise absolutely factory-stock postgresql.conf. The hardware is a not-so-new-anymore Dell P4 with run-of-the-mill IDE disk drive, running RHL 8.0. Obviously none of this is tuned at all, but the question is why did CVS tip get faster when it should by rights be slower. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] compile warnings
In addition to the ecpg warnings mentioned by Tom, I'm also seeing compile warnings wrt plpython: make[3]: Entering directory `/opt/src/pgsql-cvs/pgsql-7.5/src/pl/plpython' gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -I. -I/usr/include/python2.3 -I../../../src/include -D_GNU_SOURCE -I/usr/include/et -c -o plpython.o plpython.c -MMD In file included from /usr/include/python2.3/Python.h:8, from plpython.c:58: /usr/include/python2.3/pyconfig.h:847:1: warning: "_POSIX_C_SOURCE" redefined In file included from /usr/include/stdio.h:28, from ../../../src/include/c.h:60, from ../../../src/include/postgres.h:48, from plpython.c:37: /usr/include/features.h:131:1: warning: this is the location of the previous definition ar crs libplpython.a plpython.o Joe ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Adding column comment to information_schema.columns
Hi all,
Not sure how worthwhile others will find this small patch (to CVS HEAD),
but we found it useful. It adds the column comments to the
information_schema.columns view.
Hope it's useful.
:-)
Regards and best wishes,
Justin Clift
*** information_schema.sql.orig 2004-07-01 11:59:26.0 +1000
--- information_schema.sql 2004-07-01 12:33:01.0 +1000
***
*** 442,448
CAST(null AS cardinal_number) AS maximum_cardinality,
CAST(a.attnum AS sql_identifier) AS dtd_identifier,
!CAST('NO' AS character_data) AS is_self_referencing
FROM (pg_attribute a LEFT JOIN pg_attrdef ad ON attrelid = adrelid AND attnum =
adnum),
pg_class c, pg_namespace nc, pg_user u,
--- 442,450
CAST(null AS cardinal_number) AS maximum_cardinality,
CAST(a.attnum AS sql_identifier) AS dtd_identifier,
!CAST('NO' AS character_data) AS is_self_referencing,
!
!col_description(a.attrelid, a.attnum) AS column_comment
FROM (pg_attribute a LEFT JOIN pg_attrdef ad ON attrelid = adrelid AND attnum =
adnum),
pg_class c, pg_namespace nc, pg_user u,
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
[HACKERS] suggestion: set default statistics to 100 for numerics
Seeing how small storage for a number type is compared to a text type, and seeing how they tend to be queried on a lot, shouldn't it be reasonable for the default stats number for numerics to be 100 instead of 10? ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] xeon processors
Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] (Jaime Casanova) would write: > Can anyone tell me if postgresql has problems with xeon processors? > > If so, there is any fix or project of fix it? Well, there's a known issue that IA-32 systems with more than 4GB of memory use an extension known as "PAE" to bank-switch between the banks of memory. Any time you switch banks, there's a fair little bit of work to be done. That includes multitasking systems that need to context switch a few thousand times per second. The "fix" for this problem is to rewrite all of your applications so that they become conscious of which bits of memory they're using so they can tune their own behaviour. This, of course, requires discarding useful notions such as "virtual memory" that are _assumed_ by most modern operating systems. The fix is to buy hardware that hasn't been hacked up so badly. -- select 'cbbrowne' || '@' || 'ntlug.org'; http://www3.sympatico.ca/cbbrowne/lsf.html "There is something in the lecture course which may not have been visible so far, which is reality ..." -- Arthur Norman ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] ecpg glitch in CVS tip
I'm seeing this: make[4]: Entering directory `/home/postgres/pgsql/src/interfaces/ecpg/ecpglib' ... gcc -O1 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DFRONTEND -I../../../../src/interfaces/ecpg/include -I../../../../src/interfaces/libpq -I../../../../src/port -I../../../../src/include -D_XOPEN_SOURCE_EXTENDED -c -o descriptor.o descriptor.c descriptor.c: In function `ECPGset_desc': descriptor.c:460: warning: assignment from incompatible pointer type descriptor.c:438: warning: unused variable `last_di' ... Looks like that last patch needs a bit o' work yet ... regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Compile Failue on win32 - pipe.c using ereport
You are right! (goes away to sign up) Merlin Moncure wrote: p.s. this probably belongs on win32 hackers list. Merlin ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Win32 version question
> Does the win32 build have a pg_tablespace table? are there any rows in > it? > > Was thinking the combination of the two queries would be able to > determine table space support in some fashion: > > select * from pg_class where relnamespace = (select oid from > pg_namespace where nspname = 'pg_catalog') and relname = > 'pg_tablespace'; > > select count(*) from pg_tablespace ; select count(*) from pg_tablespace; works normally, but you can do something like this: You can do this: test=# create tablespace ts location 'c:/temp'; ERROR: tablespaces are not supported on this platform test=# ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Win32 version question
On Wed, 2004-06-30 at 11:16, Merlin Moncure wrote:
> > In phpPgAdmin, I need to know if the backend supports tablespaces or
> > not. What is the most reliable way of detecting that the backend is
> the
> > win32 native version and hence does not support tablespaces? Version
> > string info?
> >
> > Or alternatively, what is the most direct way of detecting its
> presence
> > or absence, regardless of backend OS?
>
> Check the uptime...if it's greater than 7 days, it's not win32 :).
>
> Seriously, you can check the version() string. If it's got mingw init,
> it's win32 native.
>
Does the win32 build have a pg_tablespace table? are there any rows in
it?
Was thinking the combination of the two queries would be able to
determine table space support in some fashion:
select * from pg_class where relnamespace = (select oid from
pg_namespace where nspname = 'pg_catalog') and relname =
'pg_tablespace';
select count(*) from pg_tablespace ;
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] recursive SQL
On Tue, Jun 29, 2004 at 07:23:45PM +0800, Christopher Kings-Lynne wrote: > I'm a PostgreSQL developer and I would like to see an SQL99 recursive > queries feature in PostgreSQL. Me too, on bot parts. > I'm not a committer myself, so I think I should explain how things work. > We're unlike other projects that seem to accept almost anything that > comes our way. In many ways, it's the patches that the committers > reject that make PostgreSQL strong. Actaully I am a committer and I would stil not touch that part of the source as I never worked on it. I just commit patches that I can personally judge to be good. But nevertheless I would be very interested in helping with this patch as recursive query optimization was one are I wokred on for my ph.d. Granted spare time is a problem, but we should be able to finish this for 7.6. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(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: [HACKERS] Win32 version question
So it can't be compiled by other compiler? Say Digital Mars or some Microsoft or Borland compiler? Nope. It needs the GNU tool set. -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Win32 version question
On Wed, Jun 30, 2004 at 11:16:15AM -0400, Merlin Moncure wrote: > > In phpPgAdmin, I need to know if the backend supports tablespaces or > > not. What is the most reliable way of detecting that the backend is > > the win32 native version and hence does not support tablespaces? > > Version string info? > > Seriously, you can check the version() string. If it's got mingw init, > it's win32 native. So it can't be compiled by other compiler? Say Digital Mars or some Microsoft or Borland compiler? -- Alvaro Herrera () "El día que dejes de cambiar dejarás de vivir" ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Compile Failue on win32 - pipe.c using ereport
"Merlin Moncure" <[EMAIL PROTECTED]> writes: >> For the past few days I have experienced compile failure with CVS HEAD >> on win32. >> The culprit is src/port/pipe.c which uses ereport() when it only >> #includes "c.h". > Try replacing "c.h" with "postgres.h". I fixed that on the win32 > binaries and forgot to mention it. There was a recently submitted patch to change postgres.h to c.h in a bunch of src/port modules, which I applied without looking closely. Apparently it was a tad overenthusiastic. The big question here is whether pipe.c is interesting for use in frontend programs. If so, it can't use ereport/elog at all, and we'll need to change the code. If not, we can just revert the inclusion mistake. Are there failures in any other src/port modules now? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Win32 version question
> In phpPgAdmin, I need to know if the backend supports tablespaces or > not. What is the most reliable way of detecting that the backend is the > win32 native version and hence does not support tablespaces? Version > string info? > > Or alternatively, what is the most direct way of detecting its presence > or absence, regardless of backend OS? Check the uptime...if it's greater than 7 days, it's not win32 :). Seriously, you can check the version() string. If it's got mingw init, it's win32 native. Merlin PostgreSQL 7.5devel on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.2.3 mingw special 20030504 -1) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Win32 version question
In phpPgAdmin, I need to know if the backend supports tablespaces or not. What is the most reliable way of detecting that the backend is the win32 native version and hence does not support tablespaces? Version string info? Or alternatively, what is the most direct way of detecting its presence or absence, regardless of backend OS? Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Implicit casting for || (was Re: grant execute on many functions)
[ moving thread to a more appropriate list ]
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> select 'GRANT EXECUTE ON ' || 1142::regprocedure;
>> ERROR: array value must start with "{" or dimension information
>>
>> BTW, it seems like there's something pretty broken here. How did
>> arrays get into it?
> regression=# \df array_append
>List of functions
> Result data type | Schema | Name | Argument data types
> ---++--+--
> anyarray | pg_catalog | array_append | anyarray, anyelement
> (1 row)
> So the "||" operator sees (unknown, regprocedure), and make_op tries to
> coerce the unknown literal to an array of regprocedure, which of course
> fails. If instead the literal is explicitly cast:
> select 'GRANT EXECUTE ON '::text || 1142::regprocedure;
> ERROR: operator does not exist: text || regprocedure
> HINT: No operator matches the given name and argument type(s). You may
> need to add explicit type casts.
> I'm not clear on how we can do better :(. Any suggestions?
I'm not sure either, but I can't say that I like this interpretation.
I did find that if there is an implicit coercion to text then the system
will prefer a saner interpretation:
regression=# select 'GRANT EXECUTE ON ' || 1142::regprocedure;
ERROR: array value must start with "{" or dimension information
regression=# create function text(regprocedure) returns text as '
regression'# begin
regression'# return $1;
regression'# end' language plpgsql stable strict;
CREATE FUNCTION
regression=# create cast (regprocedure as text) with function text(regprocedure) as
implicit;
CREATE CAST
regression=# select 'GRANT EXECUTE ON ' || 1142::regprocedure;
?column?
-
GRANT EXECUTE ON date_mii(date,integer)
(1 row)
I'm worried though about how stable this choice is. I'm almost tempted
to add a wart in the coercion routines to discourage matching "unknown"
to "anyarray" ...
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
Re: [HACKERS] Compile Failue on win32 - pipe.c using ereport
> For the past few days I have experienced compile failure with CVS HEAD > on win32. > The culprit is src/port/pipe.c which uses ereport() when it only > #includes "c.h". Try replacing "c.h" with "postgres.h". I fixed that on the win32 binaries and forgot to mention it. p.s. this probably belongs on win32 hackers list. Merlin ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] recursive SQL
> -Original Message- > From: Andrew Overholt [mailto:[EMAIL PROTECTED] > Sent: 28 June 2004 16:45 > To: jacob koehler (RRes-Roth) > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Alexander Rüegg > Subject: Re: recursive SQL > > > * jacob koehler (RRes-Roth) <[EMAIL PROTECTED]> > [2004-06-27 20:58]: > > > > cons: > > - its not standard SQL (uses oracle style syntax) > > Besides the GPL issue, this is my biggest problem. > > > i am aware of the fact that tom lane pointed to the fact > that Andrew > > Overholt did work towards SQL99 compliant recursive > queries. it would > > be interesting to know andrews opinion how much more work would be > > needed to get a SQL99 compliant version out based on the > work he has > > done so far, and what he thinks about Evgen potemkin's > patch (i cced > > this mail to Andrew and Evgen). > > My work towards SQL-standard recursive queries is nowhere > near complete and I'm sure any patches I had are severely > rotten by now. I'll try to grab what I had and see if I can > get a patch from which people can maybe pick up. thank you for your reply. i know that sql99 recursive sql is "a beast". maybe it would be good if you have a look on evgens recent work, and try to decide if it is better to continue on his or on your work? or maybe some things from him and from you can be thrown together? > Sorry for dropping the ball on this one. I was back > finishing up my degree this past year and my current work which is a reason that i can understand very well... > isn't database-related :( . I'll see what I can do. This > would be a great feature for PostgreSQL. i perfectly agree... cheers jacob > > Andrew > ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Compile Failue on win32 - pipe.c using ereport
For the past few days I have experienced compile failure with CVS HEAD on win32. The culprit is src/port/pipe.c which uses ereport() when it only #includes "c.h". I cured the error by #including "postgres.h" - but after a bit of thought suspect that "utils/elog.h" is all that is necessary! Is anyone else able to confirm this? I am using mingw 3.1.0-1, msys 1.0.10 and gcc 3.3.1 on win 2003 server. regards Mark ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
