"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> If you'd not like to change the behavior, I would change it, OK ?
To what? I don't want to simply undo the 7.2 change.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't
"Igor Kovalenko" <[EMAIL PROTECTED]> writes:
> It does not have to be anonymous. POSIX also defines shm_open(same arguments
> as open) API which will create named object in whatever location corresponds
> to shared memory storage on that platform (object is then grown to needed
> size by ftruncate
> > Oops. How about:
> >
> > foo'; DROP TABLE t1; -- foo
> >
> > The last ' gets removed, leaving -- (81a2).
> >
> > So you get:
> > select ... '(0x81a2)'; DROP TABLE t1; -- (0x81a2)
>
> This surely works:-< Ok, you gave me an enough example that shows even
> 7.1.x and 7.0.x are not safe.
>
>
> -Original Message-
> From: Tom Lane
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Your settings probably worked well under 7.1 but
> > doesn't in 7.2 due to the following change in
> > tcop/postgres.c.
>
> AFAIR, there is only a visible change of behavior for
> INSERT/UPDATE/DELETE
> "Igor Kovalenko" <[EMAIL PROTECTED]> writes:
> > What really need to be done is new abstraction layer which would cover
SysV
> > API, POSIX and whatever native APIs are better for BeOS/OS2/Win32. I
almost
> > did it last time...
>
> Yes. I just sent off a proposal for a cleaner semaphore API --
Like I told Marc, I don't care. You spec out what you want and I'll write it
for Windows.
That being said, a SysV IPC interface for native Windows would be kind of cool
to have.
Tom Lane wrote:
>
> mlw <[EMAIL PROTECTED]> writes:
> > I am writing a Win32 DLL implementation of :
>
> > int
Florian Weimer <[EMAIL PROTECTED]> writes:
> BTW, what about embedded NUL characters in text strings? ;-)
There's approximately zero chance of that happening in the foreseeable
future. Since null-terminated strings are the API for both the parser
and all datatype I/O routines, there'd have to be
"Igor Kovalenko" <[EMAIL PROTECTED]> writes:
> What really need to be done is new abstraction layer which would cover SysV
> API, POSIX and whatever native APIs are better for BeOS/OS2/Win32. I almost
> did it last time...
Yes. I just sent off a proposal for a cleaner semaphore API --- please
co
mlw <[EMAIL PROTECTED]> writes:
> I am writing a Win32 DLL implementation of :
> int semget(key_t key, int nsems, int semflg);
> int semctl(int semid, int semnum, int cmd, union semun arg);
> int semop(int semid, struct sembuf * sops, unsigned nsops);
Rather than propagating the SysV
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Added to TODO:
>
> * Allow backslash handling in quoted strings to be disabled for portability
BTW, what about embedded NUL characters in text strings? ;-)
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http
> mlw <[EMAIL PROTECTED]> writes:
> > I think that you should create a verbatim implementation of the SysV
> > shared memory API in native Win32. It may have to be a pgsysvshm.dll
> > or something like it, but I think it is the best possible approach.
>
> > Let me look at it, I may be able to have
Jim Mercer wrote:
> On Thu, May 02, 2002 at 09:45:45PM -0400, mlw wrote:
> > Jim Mercer wrote:
> > > On Thu, May 02, 2002 at 09:14:03PM -0400, mlw wrote:
> > > > Jim Mercer wrote:
> > > > > On Thu, May 02, 2002 at 08:41:30PM -0400, mlw wrote:
> > > > > > A mission statement is like a tie.
> > > >
Oliver Elphick <[EMAIL PROTECTED]> writes:
> current cvs would not compile. I found it necessary to make the
> following corrections:
A little software rot setting in there :-(. My compiler complained
about even more stuff than yours did. Patch applied.
regards, tom la
Tom Lane <[EMAIL PROTECTED]> writes:
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > Here are the precise conditions to trigger the scenario:
>
> > (1) the backend is PostgreSQL 6.5.x
> > (2) multibyte support is enabled (--enable-multibyte)
> > (3) the database encoding is SQL_ASCII (other encod
Neil Conway <[EMAIL PROTECTED]> writes:
> Second question: SQL92 also specifies this for SET CONSTRAINTS --
> 1) If an SQL-transaction is currently active, then let TXN be the
>currently active SQL-transaction. Otherwise, let TXN be the next
>SQL-transaction for the SQL-agent.
mlw <[EMAIL PROTECTED]> writes:
> UNIX permissions will be ignored, i.e. uig/gid will be 0
Win32 has no security anyway, right? ;-)
> Do you see any need for the msgxxx calls?
> Is the function ipc() ever used?
Nope, and nope.
regards, tom lane
---
On Fri, 3 May 2002, Neil Conway wrote:
> On Fri, 3 May 2002 10:39:28 -0700 (PDT)
> "Stephan Szabo" <[EMAIL PROTECTED]> wrote:
> >
> > On Fri, 3 May 2002, Neil Conway wrote:
> > > My reading of this: if you specify ALL, only the constraints marked
> > > as DEFERRABLE are affected. If you specify
On Fri, 3 May 2002 10:39:28 -0700 (PDT)
"Stephan Szabo" <[EMAIL PROTECTED]> wrote:
>
> On Fri, 3 May 2002, Neil Conway wrote:
> > My reading of this: if you specify ALL, only the constraints marked
> > as DEFERRABLE are affected. If you specify a specific constraint,
> > it is deferred, whether t
On Thursday 02 May 2002 11:43 pm, Lincoln Yeoh wrote:
> Any idea which versions of Postgresql have been bundled with O/S CDs?
For RedHat:
5.0 -> PG6.2.1
5.1 -> PG6.3.2
5.2 -> PG6.3.2
6.0 -> PG6.4.2
6.1 -> PG6.5.2 (I think -- this was my first RPMset in Red Hat Linux, but I'm
sysv shm/sem
I am writing a Win32 DLL implementation of :
int semget(key_t key, int nsems, int semflg);
int semctl(int semid, int semnum, int cmd, union semun arg);
int semop(int semid, struct sembuf * sops, unsigned nsops);
int shmctl(int shmid, int cmd, struct shmid_ds *buf);
i
On Fri, 3 May 2002, Neil Conway wrote:
> Hi all,
>
> The SQL92 spec has this to say about SET CONSTRAINTS DEFERRED:
>
> a) If ALL is specified, then the constraint mode in TXN of all
>constraints that are DEFERRABLE is set to deferred.
>
> b) Otherwise, the constraint mode in TXN
Hi all,
The SQL92 spec has this to say about SET CONSTRAINTS DEFERRED:
a) If ALL is specified, then the constraint mode in TXN of all
constraints that are DEFERRABLE is set to deferred.
b) Otherwise, the constraint mode in TXN for the constraints
identified by the s in the
On Thu, 2 May 2002, Jim Mercer wrote:
> On Thu, May 02, 2002 at 08:41:30PM -0400, mlw wrote:
> > A mission statement is like a tie.
>
> straw vote!
>
> who on the list wears ties?
Does a skinny black tie count if I'm only wearing it to go out to a jazz
club? :-) Not at work though. I think
Mark kirkwood <[EMAIL PROTECTED]> writes:
> On Fri, 2002-05-03 at 04:25, mlw wrote:
>
> >
> > IMHO, if we can come up with a strong, positive statement, it
> > would help MBA trained CIOs and CTOs choose PostgreSQL. To them,
> > it will show a professional minded development group, it will be
>
Tom Lane wrote:
>
> mlw <[EMAIL PROTECTED]> writes:
> > I think that you should create a verbatim implementation of the SysV
> > shared memory API in native Win32. It may have to be a pgsysvshm.dll
> > or something like it, but I think it is the best possible approach.
>
> > Let me look at it, I
mlw <[EMAIL PROTECTED]> writes:
> I think that you should create a verbatim implementation of the SysV
> shared memory API in native Win32. It may have to be a pgsysvshm.dll
> or something like it, but I think it is the best possible approach.
> Let me look at it, I may be able to have something
"Marc G. Fournier" wrote:
>
> On Fri, 3 May 2002, Tom Lane wrote:
>
> > "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > > All I'm planning on doing is changing the appropriate shm_* functions iwth
> > > pg_shm_* functions ... if !(libapr), all those pg_shm_* functions will
> > > have in them
Tom Lane wrote:
>
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > All I'm planning on doing is changing the appropriate shm_* functions iwth
> > pg_shm_* functions ... if !(libapr), all those pg_shm_* functions will
> > have in them is the original call we've always used ... there will even
On Fri, 3 May 2002, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > All I'm planning on doing is changing the appropriate shm_* functions iwth
> > pg_shm_* functions ... if !(libapr), all those pg_shm_* functions will
> > have in them is the original call we've always used ..
Hannu Krosing <[EMAIL PROTECTED]> writes:
> On Thu, 2002-05-02 at 16:52, Tom Lane wrote:
>> If we used PID then we'd eventually have 64K (or whatever the range of
>> PIDs is on your platform) different pg_temp_nnn entries cluttering
>> pg_namespace.
> Should they not be cleaned up at backend exit
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> All I'm planning on doing is changing the appropriate shm_* functions iwth
> pg_shm_* functions ... if !(libapr), all those pg_shm_* functions will
> have in them is the original call we've always used ... there will even be
> a --disable-libapr con
On Thu, 2002-05-02 at 16:52, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Is "PROC array slot number" something internal to postgres ?
>
> Yes.
>
> If we used PID then we'd eventually have 64K (or whatever the range of
> PIDs is on your platform) different pg_temp_nnn entries
On Fri, 3 May 2002, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > The initial changes will be to just wrapper all our shared memory
> > code, so that I can make use of Apache's libapr libraries *if* they are
> > installed ... if not, it will just fall back to "the curre
Hi Marc,
How about using Dev-C++?
It's a Windows IDE with a GCC backend, and has a nice rep (and a Linux
port):
http://sourceforge.net/projects/dev-cpp/
It's always in SF.net's "Top 10" most worked on projects too, with about
roughly 7,000 downloads per day. It can generate mingwin code too.
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> The initial changes will be to just wrapper all our shared memory
> code, so that I can make use of Apache's libapr libraries *if* they are
> installed ... if not, it will just fall back to "the current code" ...
I think we should redesign th
> Is there any rhyme or reason to these ISO format date parsing rules?
Yes. Though adjustments to the rules are possible, so things are not set
in concrete. There *should* be a complete description of the date/time
parsing rules in the User's Guide appendix.
> Why can't someone store the year wi
On Fri, 3 May 2002, Travis Hoyt wrote:
> Will there really be a need for a BeOS development with the sale of Be to
> Palm? Is BeOS even still available? It might not be worth the time to
> develop for BeOS until you see what Palm decides to do with the software.
Note that the changes I'm makin
Manfred Koizar <[EMAIL PROTECTED]> writes:
> Proposal 2: Let BITMAPLEN calculate the minimum number of bytes
> necessary to have one bit for every attribute.
> #define BitMapBytes 1
> old old new new
> NATTS BITMAPLEN THSIZE BITMAPLEN THSIZE
> 8436
Will there really be a need for a BeOS development with the sale of Be to
Palm? Is BeOS even still available? It might not be worth the time to
develop for BeOS until you see what Palm decides to do with the software.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
On Fri, 3 May 2002, mlw wrote:
> "Marc G. Fournier" wrote:
> >
> > Morning all ...
> >
> > Just a heads up that over the next little while, I'm planning on
> > making a bunch of commits in order to work on making the code able to work
> > natively in the above environments ... my work wil
"Marc G. Fournier" wrote:
>
> Morning all ...
>
> Just a heads up that over the next little while, I'm planning on
> making a bunch of commits in order to work on making the code able to work
> natively in the above environments ... my work will mostly focus on Win32
> (since I have no O
On Thu, 2 May 2002, Scott Marlowe wrote:
> On 2 May 2002, Hannu Krosing wrote:
>
> > The Politically Correct mission statement follows:
> >
> > The PostgreSQL community is committed to creating and maintaining a good
> > but not the best, mostly reliable, open-source multi-purpose standards
> > b
Morning all ...
Just a heads up that over the next little while, I'm planning on
making a bunch of commits in order to work on making the code able to work
natively in the above environments ... my work will mostly focus on Win32
(since I have no OS2/BeOS installs), but alot of the chang
Le Vendredi 3 Mai 2002 02:22, Thomas Lockhart a écrit :
> "PostgreSQL is and will be the most advanced open-source database
> available anywhere."
***
The PostgreSQL community is committed to creating and main
Le Vendredi 3 Mai 2002 04:46, mlw a écrit :
> Corporate bullshit or not, it is a fact of life and a custom that we open
> source people need to accept. We write the best shit, we do the best work.
> We are "more professional" and dedicated than most professionals. Our
> quality is usually much bet
On Wed, Apr 24, 2002 at 06:13:28PM -0400, Tom Lane wrote:
>
> Is that sufficient? The clients probably are not affected by quite as
> many config options as the server, but they still have a nontrivial
> list. (Multibyte, SSL, Kerberos come to mind at once.) I'd not like
> to see us assume tha
Using this configuration:
./configure --enable-locale --enable-recode --enable-multibyte
--enable-nls --with-pgport=9631 --with-CXX --with-perl --with-python
--with-tcl --enable-odbc--with-unixodbc --with-openssl --with-pam
--enable-syslog --enable-debug --enable-cassert --enable-depend
--with-t
Or else people in our situation where it takes forever to upgrade the
software because of its heavy use and the risk involved in upgrading, not
to mention the problems encountered when we did test-runs of the upgrade.
Then there is always the thorny issue of loads of software that uses the
datab
On Thu, 02 May 2002 21:10:40 -0400, Tom Lane wrote:
>Hmm ... that might work. Actually, we are trying to stuff *five*
>numbers into these fields: xmin, xmax, cmin, cmax, and a VACUUM FULL
>transaction id (let's call it xvac just to have a name). The code
>currently assumes that cmin is not inte
Tom Lane wrote in another tread:
> PS: I did like your point about BITMAPLEN; I think that might be
> a free savings. I was waiting for you to bring it up on hackers
> before commenting though...
So here we go...
Hi,
in htup.h MinHeapTupleBitmapSize is defined to be 32, i.e. the bitmap
uses at
Hi,
Is there any rhyme or reason to these ISO format date parsing rules?
test=# select '1-1-1'::date;
ERROR: Bad date external representation '1-1-1'
test=# select '69-1-1'::date;
date
2069-01-01
(1 row)
test=# select '50-1-1'::date;
date
2050-01-01
(1 row)
51 matches
Mail list logo
