To be honest this idea strikes me as overkill - over
engineering. While there is a clear need for proper CSV import
(i.e. just setting DELIMITER to ',' doesn't work due to ','s in
strings) I cannot see how this would prove useful, or who would use
it?
While i have done a lot of messing around
Shridhar, Once the patches I've put forward are applied there's still
a further change I've got planned which will remove the mutex locking
in the common case - a NULL/DEFAULT connection parameter (I'll post a
patch soon). This leaves the threaded case with comparable performance
to the
From: Bruce Momjian [EMAIL PROTECTED]
Lee Kindness wrote:
I still think it's worthwhile investigating the use of GCC's __thread
storage class specifier to remove the use of pthread_*specific in this
case. This would also be a help to the WIN32 port since this specifier
maps well
From: Bruce Momjian [EMAIL PROTECTED]
Lee Kindness wrote:
Perhaps a cleaner way is to use an existing thread package with
encompasses
the various platform APIs - i.e. APR or ACE, or... But that's a big
discussion, and not one I'm keen to get into at the moment. A more
appropriate time
From: Michael Meskes [EMAIL PROTECTED]
Why? What doesn't work? AFAIRC the AT statement does indeed allow a
variable as connection_target.
Yeah, I was wrong there. I updated the thread test program in ecpg/test to
make use of this functionality - see patch in pgsql-patches yesterday.
L.
Momjian wrote:
Should I add this to the TODO list?
--
-
Lee Kindness wrote:
Sort of related, I was thinking about adding some more thread-related
code such that if a connection wasn't explicitely specified
Just overheard one of my colleagues on the phone to one of our users
taking them through the process of moving their PGDATA to a partition
with space...
With the various paths, service names, config files and environment
variables PostgreSQL appears to have a multiple-personality
disorder... Is
Marc G. Fournier writes:
I think at this late stage in the game (almost 10 years), changing could
be a bit difficult and confusing, no? :) I'd go with something like
pgsqld myself though, keeps it short ... or we could go even shorter with
just pgd ...
But, I'm not, in any stretch
Hi, please apply patch below to correct the EXEC SQL CREATE SCHEMA
construct in ECPG. Currently (versions 7.3.x, 7.4) the preprocessor
emmits create scheme in error, rather than create schema.
A workaround also exists for those who require it (but I guess no-one
apart from me does since it's went
Tom Lane writes:
Greg Stark [EMAIL PROTECTED] writes:
On the other hand, things like, getpwnam, strtok, etc have non-thread-safe
APIs. They can never be made thread-safe. The *_r versions of these functions
are standardized and required. If they don't exist then the platform simply
Lee Kindness writes:
Tom Lane writes:
Greg Stark [EMAIL PROTECTED] writes:
On the other hand, things like, getpwnam, strtok, etc have non-thread-safe
APIs. They can never be made thread-safe. The *_r versions of these functions
are standardized and required. If they don't
Bruce Momjian writes:
Right. We can't assume because a *_r function is missing that the
normal function is thread-safe.
I recon i'll get blue in the face before long, and one of you guys
will fly over to Scotland to give me a good kicking!... But'll say it
again anyway...
That's not our
Bruce Momjian writes:
Lee Kindness wrote:
No, it's not. Using the _r functions on such systems is BETTER because
the API is clean and the function can be implmented in a reentrant and
thread-safe fashion wuithout the need for thread local storage or
mutex locking.
I don't care
Probably because I worked on thread safety and produced a patch. If
someone done the same for PITR and produced a patch i'm sure it would
have generated much more interest. I couldn't have done PITR, so no
loss of resource there.
Was Bruce planning to do the PITR work? If so I guess a lot of his
Guys, too much thought is being spent on this...
1. For the _r functions we need we should ALWAYS use them if the
system we are building on has them - they WILL be thread-safe.
2. If the system is missing a _r function then we implement a wrapper
to call the normal non-_r version. However we do
Tom Lane [EMAIL PROTECTED] writes:
Lee Kindness [EMAIL PROTECTED] writes:
Guys, too much thought is being spent on this...
1. For the _r functions we need we should ALWAYS use them if the
system we are building on has them - they WILL be thread-safe.
2. If the system is missing a _r
Larry Rosenman [EMAIL PROTECTED] writes:
then how do we *PROVE* thread-safety on a particular platform?
You're not going to be able to prove it anyway!
L.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
Bruce Momjian writes:
Marc G. Fournier wrote:
On Sat, 30 Aug 2003, Bruce Momjian wrote:
Yes, and that is the complex part because _some_ non-*_r functions are
thread-safe, and some are not. I have to determine if we have other
such platforms before I figure out how to fix it
, Lee.
Lee Kindness writes:
Tom Lane writes:
Lee Kindness [EMAIL PROTECTED] writes:
Well in that case the docs need attention. They describe the
envelope surrounding the tuples, but no mention is made of the
format they are in. It is reasonable to assume that this format
Larry, haven't managed to look at that patch... But stuffed for time
just now - just about to head off for the weekend. I'm hoping to spend
a bit of time on this on Tuesday! So, i'll see how things have
progressed then.
L.
Larry Rosenman writes:
--On Friday, August 08, 2003 11:53:34 +0100 Lee
Bruce Momjian writes:
Lee Kindness wrote:
Bruce, the changes you made yesterday to configure for
--enable-thread-safety have broken the build, at least for Linux on
Redhat 9.
OK, how did I break things? Can you show me the failure.
After a:
./configure --prefix=/var/lib/pgsql/74b
Bruce, I know it's a bit picky but both below should be along the
lines of Allow thread-safe library since they are not threaded per
se.
L.
Bruce Momjian writes:
Libpq
Allow threaded with --enable-thread-safety (Lee Kindness, Bruce)
Miscellaneous Interfaces
Allow threaded ecpg
I've not been keeping up with the thread re who has what version of
getpwuid_r... But just to clarify things the right version is:
int getpwuid_r(uid_t uid, struct passwd *pwd, char *buffer,
size_t bufsize, struct passwd **result);
documented at:
Bruce, the changes you made yesterday to configure for
--enable-thread-safety have broken the build, at least for Linux on
Redhat 9.
Also, I took the opportunity to look at port/threads.c. It is missing
important functionality compaired to the patch I originally
submitted. For getpwuid_r,
Larry Rosenman writes:
What the fr*** harm is it in passing -D_REENTRANT into the libpq build on
UnixWare
irregardless of the --with-threads* flag?
Indeed for every other sane system out there. Folk are messing around
with the thread stuff using here-say as knowledge. We want to compile
Tom Lane writes:
Lee Kindness [EMAIL PROTECTED] writes:
Well in that case the docs need attention. They describe the
envelope surrounding the tuples, but no mention is made of the
format they are in. It is reasonable to assume that this format was
the native binary format
Tom,
Tom Lane writes:
Lee Kindness [EMAIL PROTECTED] writes:
However, is COPY BINARY meant/designed to be used as transfer or
backup mechanism?
I think you're overlooking a key consideration: COPY BINARY is not
an isolated feature anymore. By design it uses the same data
Tom,
Tom Lane writes:
Lee Kindness [EMAIL PROTECTED] writes:
I've attached a patch which lets COPY read in the 7.1 format. However
i'm not convinced this is the right way to go - I think the format
which is output by 7.4 should be identical to the 7.1 format.
You are greatly
Guys, looking at ecpg from CVS HEAD's 7.4. The following code
fragement:
EXEC SQL INCLUDE sqlca;
EXEC SQL WHENEVER SQLERROR call sqlprint;
void lofsdb_GetMinMaxRxStations(int *from, int *to)
{
EXEC SQL BEGIN DECLARE SECTION;
int l_from = 0;
int l_to = 0;
EXEC SQL END DECLARE
Guys,
I've been testing 7.4 against an application today. Recompiled
everything against the new libraries. However the application includes
code which builds up a bulkload file in the documented 7.1 format. The
documentation for COPY goes on at length about the format being
forward compatible...
Guys, take a look at what was done in libpq to make it
thread-safe... No locks! No overheaded - just using proper reentrant
functions...
If we have libpq_r then we're making a complete hash of it all - being
reentrant is good, even if you're not using threads!
Now, ecpg is another issue...
L.
Bruce Momjian writes:
Lee Kindness wrote:
Guys, take a look at what was done in libpq to make it
thread-safe... No locks! No overheaded - just using proper reentrant
functions...
If we have libpq_r then we're making a complete hash of it all - being
reentrant is good, even
Tom Lane writes:
Lee Kindness [EMAIL PROTECTED] writes:
Bruce Momjian writes:
My guess is that if the OS has separate threaded libs, we have to mimic
that stuff.
But there are NO thread primitives/calls in libpq
That's not the point. The point is stuff that isn't necessarily
Tom Lane writes:
If the OS supplies both libc and libc_r, it is unlikely to be a good
idea to link a threaded libpq with libc, or a non-threaded libpq with
libc_r.
What modern OS has libc_r? The majors (Linux, Soalris, HPUX, AIX)
certainly do not.
L.
---(end of
Tom Lane writes:
Bruce Momjian [EMAIL PROTECTED] writes:
Now I see what you are saying, that _REENTRANT just makes it reentrant,
and doesn't have a downside in terms of performance.
That's at best an unsupported assertion. Why would the platform bother
with supplying two copies of
Bruce Momjian writes:
However, notice the flags needed under Linux:
THREAD_CFLAGS=-D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS
or are you saying libpq needs only the first one because libpq, itself,
doesn't use threads --- interesting distinction, and perhaps a way we
Bruce Momjian writes:
Peter Eisentraut wrote:
Bruce Momjian writes:
THREAD_CFLAGS=-D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS
Those flags are bogus. You don't need any flags under Linux.
Is that true for all versions of Linux? Don't we need the first one so
we compile
Peter Eisentraut writes:
Larry Rosenman writes:
I beg to differ. Explicitly, on UnixWare, the errno.h header,
reproduced below, under fair use, show an EXPLICIT difference in what
happens with _REENTRANT:
Hmm, I was too optimistic. I guess we'll just have to handcraft a
different
Guys, attached is a patch to fix two memory leaks on start-up. The
first is when freeaddrinfo has been used to free memory allocated by
getaddrinfo2 (so freeaddrinfo2 should be used). The second is 2 leaks
when creating the lock (PostgreSQL and socket) files.
The diff is against last night's CVS
It was in libpq in my original patch, not port.
L.
Peter Eisentraut writes:
I have a few problems with the file threads.c:
1. It doesn't contain any threads, so the name is slightly inappropriate.
2. It's not a porting module (since pqStrerror, etc. are not system
functions), so it
Tom Lane writes:
Lee Kindness [EMAIL PROTECTED] writes:
I'd have to disagree with regards to the memory leaks not being worth
a mention - any such leak can cause problems when the PostgreSQL
installation is either unattended, long-living andor has very high
connection levels.
I
negligible in
this light.
Regards, Lee.
Tom Lane writes:
Lee Kindness [EMAIL PROTECTED] writes:
Guys, attached is a patch to fix two memory leaks on start-up.
I do not like the changes to miscinit.c. In the first place, it is not
a memory leak to do a one-time allocation of state
Guys, surely some one's done this before? I've tried using
PQescapeBytea too, but still get (slightly) different output. If I try
and insert \x02\x01\x02\x03\x04hello\x05\x64\x99\x45 I get (int
values of chars printed):
INSERT: 2 1 2 3 4 104 101 108 108 111 5 100 -103 69
SELECT: 2 1
strerror */
return strerror(errnum);
#endif
}
Why do we have to care about HAVE_NONPOSIX_STRERROR_R? Can't we just
use the HAVE_STRERROR_R code in all cases?
---
Lee Kindness wrote:
Content
Bruce Momjian writes:
My point is why do we care whether it returns char * or nothing --- we
should just return strerrbuf in all cases.
Ok, I see. Guess that is reasonable.
L.
---(end of broadcast)---
TIP 7: don't forget to increase your free
Philip,
You can find the patch so far at:
http://services.csl.co.uk/postgresql/
along with a libpq thread-safe patch.
The thread referenced by Bruce's email details some of the issues
still to be looked at. The main work is integration with the build
system (testing for and linking in POSIX
, but you need to invoke the cc -Kpthread
option.
LER
-
--
Lee Kindness wrote:
Philip,
You can find the patch so far at:
http://services.csl.co.uk/postgresql/
along
For those using Linux, the RPMs at:
http://services.csl.co.uk/postgresql/
are probably handy.
L.
Bruce Momjian writes:
Sorry, I meant bison 1.875 is now required, not 1.85.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] |
Larry Rosenman writes:
[EMAIL PROTECTED] wrote:
Bison is 1.28. Yacc (version 91.7.30) gives a similar error.
you need Bison 1.50 or later...
Which you can get binary and src RPMs of from:
http://services.csl.co.uk/postgresql/
L:
---(end of
Okay guys, i've been a bit tight of time recently to move forward on
this, but I plan to do a small amount of work on the patches to clean
them up so they can be merged into the sources.
I'll also add a README to document what will need to be fudged in the
makefile to get it building. Hopefully
Michael,
Michael Meskes writes:
On Thu, Jan 23, 2003 at 02:40:33PM +0530, Shridhar
Daithankar[EMAIL PROTECTED] wrote:
I would like to use ECPG as it is relatively easy to code. However my
application is multithreaded and also uses connecion pools.
I'm afraid it needs some work to
Michael Meskes writes:
On Mon, Jan 27, 2003 at 11:52:18AM +, Lee Kindness wrote:
I've spent a bit of time on making ecpg thread safe over Christmas,
while it's not finished i'm sure the attached patch is at least useful
and a step in the right direction.
Thanks a lot. I have
Shridhar Daithankar writes:
On 27 Jan 2003 at 14:06, Lee Kindness wrote:
Michael Meskes writes:
Thanks a lot. I have no experience in multithreaded software development
so I cannot completely check your patch but it surely looks good. Shall
I commit it, or will you? I think we
?
Thanks, Lee.
Peter Eisentraut writes:
Lee Kindness writes:
Patches attached to make libpq thread-safe, now uses strerror_r(),
gethostbyname_r(), getpwuid_r() and crypt_r() where available. Where
strtok() was previously used strchr() is now used.
AC_TRY_RUN tests are prohibited. Also
Tom,
Tom Lane writes:
Lee Kindness [EMAIL PROTECTED] writes:
+ #define _THREAD_SAFE
+ #define _REENTRANT
+ #define _POSIX_PTHREAD_SEMANTICS
What is this stuff, and why isn't it wrapped in any sort of
platform-specific test? If it's needed, why is it in only one .c
file?
It's
in the configure stuff is
100% right...
Patches also at:
http://services.csl.co.uk/postgresql/diffs-20030109-configure.txt.gz
http://services.csl.co.uk/postgresql/diffs-20030109-libpq.txt.gz
Thanks, Lee.
Lee Kindness writes:
Tom Lane writes:
Bruce Momjian [EMAIL PROTECTED] writes
Tom Lane writes:
Bruce Momjian [EMAIL PROTECTED] writes:
We have definatly had requests for improved thread-safeness for libpq
and ecpg in the past, so whatever you can do would be a help. We say
libpq is thread-safe, but specifically mention the non-threadsafe calls
in the libpq
Bruce Momjian writes:
Lee Kindness wrote:
Right, so a reasonable angle for me to take is to go through the libpq
source looking for potential problem areas and use of known bad
functions. I can add autoconf checks for the replacement *_r()
functions, and use these in place
Guys, for your convenience i've put online a source RPM for Bison
1.875 along with binary RPMs for Redhat 7.2, 7.3 and 8.0. Hunting
around the net i didn't find any existing Bison = 1.50 RPMs, so this
should be useful for those compiling PostgreSQL (ECPG in particular)
from the CVS source:
On a slightly related note to the other threads thread [sic] going
on... Over the Christmas/New Year break i've been looking into making
the PostgreSQL client libraries (in particular libpq and ecpg)
thread-safe - that is they can safely be used by a program which
itself is using mutliple threads.
Tom Lane writes:
Lee Kindness [EMAIL PROTECTED] writes:
On a slightly related note to the other threads thread [sic] going
on... Over the Christmas/New Year break i've been looking into making
the PostgreSQL client libraries (in particular libpq and ecpg)
thread-safe
Guys,
I've been asked by a colleague about methods to keep track of
'previous' contents of a table - i.e. changes made and a way of
getting back to a previous state. Now, I know INSERT/UPDATE/DELETE
triggers to maintain an accompanying table is a way to do this. But, I
have a nagging feeling that
Jeroen T. Vermeulen writes:
On Mon, Dec 16, 2002 at 05:41:06PM +0100, Jeroen T. Vermeulen wrote:
Speaking of which, what if user relies on sizeof(PGnotify::relname)?
^
code
Yes, a change in the size of relname makes this
Guys, can I take this chance to summarise the thread and when the
major and minor versions should be updated, perhaps could be added to
the developers FAQ if everyone is in agreement?
Major Version
=
The major version number should be updated whenever the source of the
library
Guys,
Some further comments on bumbing the major version number which aren't
so cut-n-dry...
Lee Kindness writes:
The major version number should be updated whenever the source of the
library changes to make it binary incompatible. Such changes include,
but limited to:
1. Removing
Dan Langille writes:
On 10 Dec 2002 at 9:34, Tom Lane wrote:
Anyone running cvsup would have a complete copy of the source CVS, I
believe. It would be more troubling to reconstruct the mailing list
archives; I'm not sure that those are mirrored anywhere
Do you mean the repository, or
Ian Barwick writes:
On Tuesday 10 December 2002 00:47, Tom Lane wrote:
In the next protocol version update (hopefully 7.4) I would like to see
the basic version string (eg, 7.3.1 or 7.4devel) delivered to the
client automatically during connection startup and then available from a
Tom Lane writes:
Lee Kindness [EMAIL PROTECTED] writes:
Tom Lane writes:
Okay, so it seems -D_REENTRANT is the appropriate fix.
However, _REENTRANT is not a Solarisism... On all (recent) UNIX
systems it toggles on correct handling for thread specific instances
of historically
Tom Lane writes:
Okay, so it seems -D_REENTRANT is the appropriate fix.
We could either add that to the template/solaris file, or just add a
note to FAQ_Solaris advising that it be added to the configure switches
if people intend to use libpq in threaded programs. Is there any
cost
Bruce Momjian writes:
Tom Lane wrote:
Lee Kindness [EMAIL PROTECTED] writes:
Perhaps the .so name should have been updated for PostgreSQL 7.3?
It should have been. If it wasn't, that was a serious oversight.
Not sure if we should change it in 7.3.1 or not, though; it may
Perhaps the .so name should have been updated for PostgreSQL 7.3? For
example in 7.2 libpq is:
/usr/lib/libpq.so - libpq.so.2.2
/usr/lib/libpq.so.2 - libpq.so.2.2
/usr/lib/libpq.so.2.0 - libpq.so.2
/usr/lib/libpq.so.2.2
and PostgreSQL 7.3:
/usr/lib/libpq.so - libpq.so.2.2
of
lines.
And that's not all :(
I have other applications like phprojekt that was not developed by me and
became useless now as I cant insert.
Was this step so necessary ?
- Original Message -
From: Lee Kindness [EMAIL PROTECTED]
To: Ben-Nes Michael [EMAIL PROTECTED
Christopher Kings-Lynne writes:
Just out of interest, if someone was going to pay you to hack on Postgres
for 6 months, what would you like to code for 7.4?
Well judging by the hoards on Slashdot, it would appear that
replication is the hot enhancement...
Slashdot | PostgreSQL 7.3 Released
Tom/Hackers,
Going back a bit, but relevant with 7.3's release...
Tom Lane writes on 03 Sep 2002:
Lee Kindness [EMAIL PROTECTED] writes:
[ original post was regarding the mileage in adding utility
functions to PostgreSQL to cut-out common catalog lookups, thus
making apps less
See:
http://www.us.postgresql.org/users-lounge/docs/7.2/postgres/catalogs.html
for PostgreSQL 7.2.x, for 7.3 see:
http://developer.postgresql.org/docs/postgres/catalogs.html
Lee.
Steve Jackson writes:
Hi
Has anyone of you a good pointer to a description of where in the system
... Or settle for the existing, non-native, Windows
version.
By the way, just to open Office documents? Have you tried OpenOffice?
Regards, Lee Kindness.
Al Sutton writes:
Is there a rough date for when they'll be available?
I have a development team at work who currently have an M$-Windows
Marc,
Marc G. Fournier writes:
if (ic_flag == 1) {
/*only select those non-IC/Spyder nodes that has full update set*/
EXEC SQL DECLARE full_dyn_node CURSOR FOR
SELECT node_name FROM NODE
WHERE dynamic_community = 'f' AND
TABLE rather than COPY - this would allow a well
designed and thoughtout syntax for the new version while retaining old
compatibility.
egards, Lee Kindness.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Dave Page writes:
Just because I'm curious, is *all* new stuff going to Gborg, and is the
existing /contrib going to migrated there?
I'm curious too...
If that is to happen then the profile of gborg would need to be
massively increased. Currenly the only real link on the 'net to gborg
(by
first there's no
simple way already!
Regards, Lee Kindness.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Tom, do you think there is millage in adding functions (at least to
contrib) to PostgreSQL to avoid some of the common tasks applications
look into pg_* for?
For example I recently audited our code here for pg_* access, and
managed to create two plpgsql functions to replace all
occurrences. They
I'd have thought that if a matching user couldn't be found in the
specified database then it would default to searching through the
global users? Would be more intuitive...
Lee.
Bruce Momjian writes:
Sample run:
$ psql -U postgres test
psql: FATAL: user postgres@test does not
Vince Vielhaber writes:
[ 'user@' patch ]
whim. Then again as long as 7.2.1 is stable enough for me there's
no reason to upgrade 'cuze I damn sure ain't going back and changing
all sorts of programs and scripts that have global users.
Having read bits and pieces of this thread, can
a
[29189]: raising sqlcode -400 in line 21, ''ERROR: parser: parse error at or near
a' in line 21.'.
Regards, Lee Kindness.
Bruce Momjian writes:
Has this been addressed? Can you supply a reproducable example?
Edward Pilipczuk wrote:
On Monday, 22 April 2002 18:41, you wrote:
Edward
*!*!* Error -220: No such connection NULL in line 21.
Wow, how did that A get into the query string:
insert into tab1 ( col1 ) values ( -6.002122251e-06A )
Quite strange. Michael, any ideas?
Lee Kindness wrote:
Content-Description: message body text
Bruce
floattest@localhost:5433
Regards, Lee Kindness.
Bruce Momjian writes:
I am now getting this error:
#$ ./a.out floattest
col1: -0.06
*!*!* Error -220: No such connection NULL in line 21.
I will wait for Michael to comment
Thomas Lockhart writes:
Right. IBM.
Most likely they have fixed it by now ...
Nope, though I don't know for sure. Anyone here have a recent AIX
machine to test?
Well on AIX 4.3.3 the output from Lamar's earlier test program is:
The system thinks 11/30/1969 is a timestamp of -1
and
for some documentation on this
aspect.
Regards, Lee Kindness.
Christof Petig writes:
Michael Meskes wrote:
On Thu, Apr 25, 2002 at 12:42:00PM +0100, Lee Kindness wrote:
Should the input pointers be NULL initialised? How should the memory
be freed?
A simple free() will do. You also
Marc G. Fournier writes:
Myself, I wonder why Oracle went the route they went ... does anyone have
access to a Sybase / Informix system, to confirm how they do it? Is
Oracle the 'odd man out', or are we going to be that? *Adding* something
(ie. DROP TABLE rollbacks) that nobody appears
initialised before each fetch, or
only before the first one? How should the memory be freed?
Any pointers to useful documentation?
Thanks, Lee Kindness.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http
Peter Eisentraut writes:
Lee Kindness writes:
Touche, but the man page for the front-end (plain old cc) doesn't list
options and only refers to the acc man page ;)
Well, I'm stumped. All the Solaris compilers I've ever seen did support
and document the -Wl option.
Well I never
a similar patch to Denis's (without the wierd hi-ascii
characters in his) lying around for when i build a Solaris version.
Regards, Lee Kindness.
Peter Eisentraut writes:
Denis A Ustimenko writes:
[change -Wl,-R to -R and -Wl,-h to -h]
I'm having a difficult time understanding this. Both -R
See the pg_database table:
http://www.postgresql.org/idocs/index.php?catalog-pg-database.html
Regards, Lee.
Ron de Jong writes:
All,
How do I get a list of DB's or Tables with a postgres SQL statement?
It needs to be an SQL statement otherwise perl/DBI/prepare won't parse it.
I
to be changed to
reserved since it can no-longer be used as an unquoted column
identifier?
Perhaps the other time related identifiers too.
Regards, Lee Kindness.
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
Bill Studenmund writes:
I think this patch is wrong. Wouldn't it be better to make the line number
in yylineno be correct? Also, there are users of the line number in pcg.l
which you didn't change.
Looking at it, I don't see why the line number is off. It is initialized
to 1 at the
Bruce Momjian writes:
Lee Kindness writes:
In which case a number of other cases should be weeded out of
parser.y and passed onto the backend:
[ snip ]
Let me known if you want a patch for these cases too.
Sure, send them on over.
Patch below, it changes:
1. A number of mmerror
Tatsuo Ishii writes:
I saw over 7 hours delay between postgresql.org and sever1.pgsql.org.
Does anynone know what's happening here?
I've seen massive delays too:
Received: from mail.csl.co.uk by euphrates.csl.co.uk (8.9.3/ConceptI 2.4)
id EAA08864; Tue, 16 Oct 2001 04:24:41 +0100
session_user
setof
show
some
substring
table
then
time
timestamp
to
trailing
transaction
trim
true
union
unique
unknown
user
using
vacuum
varchar
verbose
when
where
Best Regards, Lee Kindness..
---(end of broadcast
Tom Lane writes:
Lee Kindness [EMAIL PROTECTED] writes:
The existing code in ecpg/preproc/preproc.y to handle the WITH option
simply throws an error and aborts the processing... The patch below
prevents the segfault and also passes on the WITH option to the
backend, probably
Tom Lane writes:
Uh, isn't the correct fix
! $$ = cat_str(8, make_str(grant), $2, make_str(on), $4, $5,
make_str(to), $7, $8);
ISTM your patch loses the opt_with_grant clause. (Of course the
backend doesn't currently accept that clause anyway, but that's no
reason for ecpg to drop
1 - 100 of 108 matches
Mail list logo
