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 read
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
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
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 non-threade
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.
gt; application gets.
>
> And on the plus side we don't have to worry about platform specific
threading
> models either.
>
> Thoughts?
>
> Shridhar
>
> Bruce Momjian wrote:
>
> > Should I add this to the TODO list?
> >
>
> -
Sort of related, I was thinking about adding some more thread-related
code such that if a connection wasn't explicitely specified then the
last connection SET or CONNECTed to for the current thread is used,
rather than just the "last connection".
But yeah, specifying the connection by variable (be
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 stre
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 it
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 w
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
>
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 co
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
> &
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 sim
"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?
htt
"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
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
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
t
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 h
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:
./con
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
hanks, 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
> > >
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
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:
http://www.opengroup.org/onl
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, gethostb
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,
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 anymor
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 t
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 identi
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, 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 SECTION
Peter Eisentraut writes:
> Larry Rosenman writes:
> > I beg to differ. Explicitly, on UnixWare, the 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
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
>
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
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 copie
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 b
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
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 has
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.
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 and
isn't 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 "memo
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),
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 H
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
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
cases?
>
> ---
>
> Lee Kindness wrote:
> Content-Description: message body text
>
> > Patch attached, along with new libpq-reentrant.c and libpq-reentrant.h
> > files for src/interfaces/
t; I can help with the UnixWare threads stuff. Also, Micheal Meskes now has
> > an account
> > on my UnixWare box.
> >
> > The threads are native on UW, but you need to invoke the cc -Kpthread
> > option.
> >
> > LER
> >
> > >
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
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 broadcast)-
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 th
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
>
Michael Meskes writes:
> On Mon, Jan 27, 2003 at 11:52:18AM +0000, 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
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
und acceptable?
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
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
t use 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 P
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()
> &
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 th
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
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.
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:
http:
Tom Lane writes:
> Lee Kindness <[EMAIL PROTECTED]> writes:
> > I have a nagging feeling that somebody has at one point put together
> > such a feature in a generic fashion... I thought there was a 'time
> > machine' module in contrib!
> contrib/spi
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 thi
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 limite
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 changes
Making something binary incompatible IS an API change! In the case in
question an externally visible structure definition was changed -
clearly a change of API...
Bruce Momjian writes:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > So if a recompile fixes it, increment mi
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 fr
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 reposit
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 handlin
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
> c
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
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
e (''); ?
>
> Who knows how many application will suffer becouse of this.
>
> - Original Message -
> From: "Bruce Momjian" <[EMAIL PROTECTED]>
> To: "Lee Kindness" <[EMAIL PROTECTED]>
> Cc: "Ben-Nes Michael" <
on all my projects and change thousands 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 --
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 cat
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
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
> t
with
Linux installed... 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 te
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 ic_f
er
for a purely grammatical reason!
A good few months ago I put formward an idea to change (well migrate
really) to "COPY 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
, but would like to check 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 n
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 t
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
roblem on my machine:
>
> #$ ./a.out floattest
> col1: -0.06
> *!*!* 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-
RROR: parser: parse error at or near "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
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
a
d 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
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 appea
ULL 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?
h
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
>
Peter Eisentraut writes:
> Lee Kindness writes:
> > For your information I've attached the man page for the Sun C
> > compiler, which explicitly lists the -h and -R flags.
> I didn't read much farther than
> acc (SPARC only) is not intended to be used
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
x27;.
I keep 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 ha
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
eds 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 ap
1 - 100 of 113 matches
Mail list logo
