Neil Conway <[EMAIL PROTECTED]> writes:
> (1) Use the shared-memory-based buffer scheme you suggested. When a
> backend executes a NOTIFY, it stores it until transaction commit (as in
> current sources). When the transaction commits, it checks to see if
> there would be a buffer overflow if it add
On Thu, 2002-03-21 at 22:41, Tom Lane wrote:
> It might be a workable tradeoff to cope with
> buffer overrun for LISTEN/NOTIFY by reporting notifies on all conditions
> currently listened for. Assuming that overrun is infrequent, the net
> performance gain from being able to use shared memory is
I want to change the code that maintains the pg_shadow password cache
into the format used by pg_hba.conf so they can all use the same code.
This will allow me to cleanly use the pg_shadow code for pg_group cache
too because the pg_shadow cache has binary searching for lookups. I
will merge the
Thomas Lockhart wrote:
> ...
> > "CREATE TABLE test (x int NULL)" doesn't look great either. :-) What
> > is that NULL doing there?
>
> Well, because NOT NULL *was* in the standard, and because one should be
> able to explicitly negate *that*. The alternative was
>
> CREATE TABLE test (x int
...
> "CREATE TABLE test (x int NULL)" doesn't look great either. :-) What
> is that NULL doing there?
Well, because NOT NULL *was* in the standard, and because one should be
able to explicitly negate *that*. The alternative was
CREATE TABLE test (x int NOT NOT NULL)
:O
Tom Lane wrote:
> "Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
> > BTW, is NULLABLE so ugly that no one wanted to comment on it?
>
> I kinda liked it, actually, if we were going to use the SET syntax.
> But people seem to be focused in on this "let's make it look like
> CREATE" notion. I'm wi
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > My assumption is that text files should use "r" and binary files use
> > PG_BINARY_R.
>
> I believe that's correct. It seems kinda inconsistent though.
>
> > For example, in 7.2 I see pg_hba.conf opened with "r" and pg_ident.conf
>
On Fri, 2002-03-22 at 14:00, Ross J. Reedstrom wrote:
> BTW, is NULLABLE so ugly that no one wanted to comment on it? It _is_
> an sql92 reserved keyword, and it's actual english grammar.
FWIW, I liked it the best of all the solutions that have been proposed
so far.
Cheers,
Neil
--
Neil Conwa
"Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
> BTW, is NULLABLE so ugly that no one wanted to comment on it?
I kinda liked it, actually, if we were going to use the SET syntax.
But people seem to be focused in on this "let's make it look like
CREATE" notion. I'm willing to wait and see how fa
Bruce Momjian <[EMAIL PROTECTED]> writes:
> My assumption is that text files should use "r" and binary files use
> PG_BINARY_R.
I believe that's correct. It seems kinda inconsistent though.
> For example, in 7.2 I see pg_hba.conf opened with "r" and pg_ident.conf
> opened with PG_BINARY_R.
The
On Fri, Mar 22, 2002 at 01:12:09PM -0500, Tom Lane wrote:
>
> Also I agree with Fernando that trying to make the word COLUMN optional
> is likely to lead to conflicts.
According to the docs, COLUMN is _already_ optional at that point.
Are the changes past that point going to cause different prob
I am seeing conflicting usage of PG_BINARY_R and "r" in AllocateFile()
calls. Is there a logic of when to use one or the other, or is this
just badly maintained code?
The significant difference is:
#ifdef __CYGWIN__
#define PG_BINARY O_BINARY
#define PG_BIN
Igor Kovalenko wrote:
> Does that mean I should redo patch for 7.3 as is, or you guys want it to
> go farther this time? The last version had compromises intended to make
> changes minimal...
>
> Also, does anyone from Darwin or BeOS camp care? You guys should not be
> working through emulation o
mlw wrote:
> Jan Wieck wrote:
> >
> > mlw wrote:
> > > [...]
> > >
> > > IMHO modifying the function manager to allow the return of a full row, and a
> > > "set of" full rows, answers a LOT of issues I have seen over the years with
> > > PostgreSQL extensibility.
> >
> > Sure. Actually I thin
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> ALTER TABLE blah ALTER [COLUMN] col [int4] [NOT NULL] [DEFAULT 32];
> ALTER TABLE blah ALTER [COLUMN] col [int8] [NULL] [DEFAULT 32];
This cannot work unless you are prepared to turn a lot more keywords
into reserved words. In the CREATE
Does that mean I should redo patch for 7.3 as is, or you guys want it to
go farther this time? The last version had compromises intended to make
changes minimal...
Also, does anyone from Darwin or BeOS camp care? You guys should not be
working through emulation of SysV ugliness. If someone is lis
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > I don't know. Automatically modifying a manually maintained config file
> > isn't too common a feature. One problem would be if you where modifying
> > the file in your editor and the backend rewrote the file.
>
> That's not different from
Bruce Momjian writes:
> I don't know. Automatically modifying a manually maintained config file
> isn't too common a feature. One problem would be if you where modifying
> the file in your editor and the backend rewrote the file.
That's not different from you modifying the file in your editor
Peter Eisentraut wrote:
> Tom Lane writes:
>
> > I don't think GRANT CONNECT fits into our setup at all. I also doubt
> > that it will be needed very much once we have schemas.
>
> People have many times asked for a way to alter the connection settings
> from within the database. For instance,
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> OK, I'll add NAMEDATALEN, FUNC_MAX_ARGS, and LOCALE_NAME_BUFLEN. Any
> more?
No, you're missing my point: there is zero value in adding
LOCALE_NAME_BUFLEN as an explicit field in ControlFileData.
The entire physical layout of ControlFileData has to be
Zeugswetter Andreas SB SD wrote:
>
> Imho it would be nice if the command would look exactly like a create
> table. It is simply convenient to use cut and paste :-) And I haven't
> seen a keyword yet, that would make it more descriptive, certainly not SET.
>
> ALTER TABLE blah ALTER [COLUMN] col
On a side note, I thought I would mention that the Next Generation POSIX
Threading (NGPT) Project (IBM --
http://www-124.ibm.com/developerworks/projects/pthreads) patches have
just been accepted to the 2.5.x Linux kernel. A 2.4.x patch is also
available. So, it may be possible that POSIX mutexes
Tom Lane writes:
> I don't think GRANT CONNECT fits into our setup at all. I also doubt
> that it will be needed very much once we have schemas.
People have many times asked for a way to alter the connection settings
from within the database. For instance, you add users in the database,
but th
Christopher Kings-Lynne writes:
> So then how is it any more wrong than SET NOT NULL?
You're right.
> It should almost be ADD NOT NULL ...
I like that.
It also makes sense because the standard syntax is to ADD/DROP CHECK
constraints, to which NOT NULL constraints are equivalent.
--
Peter Ei
> > I notice that the compile-time locale settings are registered in that
> > same structure. And that they depend on NAMEDATALEN,
> They do? That would be fairly broken if so; sizeof(ControlFileData)
> has to be independent of configurable settings, else you'll not get as
> far as inspecting any
seems like other systems keep very similar syntax to the CREATE TABLE
command. i.e.
ALTER TABLE blah ALTER COLUMN col datatype (precision.scale) NULL
ALTER TABLE blah ALTER COLUMN col datatype (precision.scale) NOT NULL
Dwayne
---(end of broadcast)--
Hi all,
I did an initial patch for ALTER TABLE / SET NULL that should just say 'not
implemented' when someone tries it, but I get this:
template1=# alter table test alter column a set null;
ERROR: parser: parse error at or near "null"
template1=# alter table test alter column a set null_p;
ERRO
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> I notice that the compile-time locale settings are registered in that
> same structure. And that they depend on NAMEDATALEN,
They do? That would be fairly broken if so; sizeof(ControlFileData)
has to be independent of configurable settings, else you'
At Tom Lane's suggestion, I am adding a field to pg_control to hold the
compile-time configuration of timestamp and time storage.
I notice that the compile-time locale settings are registered in that
same structure. And that they depend on NAMEDATALEN, which is *not* in
that structure. istm that
> > Do we want the above syntax, or this syntax:
> >
> > ALTER TABLE blah ALTER COLUMN col SET NOT NULL;
> > ALTER TABLE blah ALTER COLUMN col SET NULL;
>
> My only objection to the second command is that it's plain wrong. You
> don't set anything to NULL, so don't make the command look like it
On Fri, 2002-03-22 at 06:40, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> >> BTW, I would like to see a spec for this "notify with parameter" feature
> >> before it's implemented, not after.
>
> > The current syntax I'm using is:
> > NOTIFY condition_name [ [WITH MESSAGE] 'my m
On March 22, 2002 01:31 am, Peter Eisentraut wrote:
> Christopher Kings-Lynne writes:
> > Do we want the above syntax, or this syntax:
> >
> > ALTER TABLE blah ALTER COLUMN col SET NOT NULL;
> > ALTER TABLE blah ALTER COLUMN col SET NULL;
>
> My only objection to the second command is that it's pl
>
> cc-1070 cc: ERROR File = xact.c, Line = 587
> The indicated type is incomplete.
>
> struct timeval delay;
struct timeval must be defined on your "include path"/sys/time.h, what have
you got?
regards
---(end of broadcast)-
33 matches
Mail list logo
