> Just seems like we'd be forcing non-standard syntax on
> ourselves when/if
> CREATE DATABASE becomes CREATE SCHEMA;
I do not think this will be the way.
> I would assume that the two
> statements would become synonymous?
No, I think we need the schema below the database hierarchy.
Thus you
> I like that a lot. Solves the whole problem at a stroke, and even
> adds some extra functionality (alternate templates).
>
> Do we need an actual enforcement mechanism for "don't modify
> template0"?
> I think we could live without that for now. If you're
> worried about it,
> one way woul
> I did, but the log didn't say anything about unfixed regression test
> cases. If you're going to leave some platform-specific comparison
> files un-updated, I think it'd be polite to warn people about that
> explicitly... probably on pghackers, not just committers...
*sigh*
I'll probably alwa
That would be an extreamly good reason then. I suppose I've fallen into
the 'other' standard :(
Tom Lane wrote:
>
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > I believe that the coalesce function can
> > get you out of this... Speaking of which, why isn't it called NVL()?
>
> Because the SQL9
Rod Taylor <[EMAIL PROTECTED]> writes:
> I believe that the coalesce function can
> get you out of this... Speaking of which, why isn't it called NVL()?
Because the SQL92 standard calls it coalesce.
regards, tom lane
Luis Magaña wrote:
>
> Hi:
>
> Have this curious situation and would like some help from you:
>
> Create an employee table:
>
> CREATE TABLE employee(
>id_employee SERIAL PRIMARY KEY,
>sex CHAR(1) DEFAULT 'm' CHECK(sex = 'f' OR sex = 'm'),
>start_date DATE NOT NULL,
>charge V
With current sources I get:
regression=# select 'foo' < 'bar';
ERROR: pg_atoi: error in "foo": can't parse "foo"
I was expecting the system to resolve this as a text comparison,
but it seems to have chosen int4 instead. This is, um, surprising
behavior.
regards, tom la
Seems to be long gone in current sources.
I think at one time the two if's probably tested different flags.
You could dig through our CVS server if you want to know the history.
regards, tom lane
Hi:
Have this curious situation and would like some help from you:
Create an employee table:
CREATE TABLE employee(
id_employee SERIAL PRIMARY KEY,
sex CHAR(1) DEFAULT 'm' CHECK(sex = 'f' OR sex = 'm'),
start_date DATE NOT NULL,
charge VARCHAR(50) NOT NULL,
last_name VARCHAR(50
Hi,
I found an unreachable block during studing the PostgreSQL 7.0.2 by
reading its souce code.
Starting from line 1383 in postgres.c
1383 if (Verbose)
1384 {
1385 if (Verbose)
1386 {
:
1389 }
1390
Jeff MacDonald,
-
PostgreSQL Inc | Hub.Org Networking Services
[EMAIL PROTECTED] | [EMAIL PROTECTED]
www.pgsql.com | www.hub.org
1-902-542-0713 | 1-902-542-3657
-
> Rollback of DROP TABLE now works in non-WAL code, and seems to work in
> WAL code too. I did not add WAL logging, because I'm not quite sure
> what to do, so rollforward probably does the wrong thing. Could you
> deal with that part? smgr.c is the place that keeps the list of what
> to delete
Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> Not sure what to do about this. It will clearly not do to define
>> ACCEPT_TYPE_ARG3 as void. Perhaps we need a special case for
>> Solaris 7: if we detect that accept() is declared with "void *",
>> assume that socklen_t is the thing to use. Pete
"Vadim Mikheev" <[EMAIL PROTECTED]> writes:
> Please note that there is xlog_bufmgr.c If you'll add/change something in
> bufmgr please let me know later.
Per your request: I've changed bufmgr.c. I think I made appropriate
changes in xlog_bufmgr, but please check. The changes were:
1. Modify F
On Mié 08 Nov 2000 18:17, Tom Lane wrote:
>
> I guess we not only need a hack, but a nastygram or three sent off to
> the Solaris people. void *? What in heavens name were they thinking?
> That essentially means you've got no parameter type checking at all
> on calls to accept() --- or any other
"Martin A. Marques" <[EMAIL PROTECTED]> writes:
> No. Forgot to tell my latest experience.
> 1) postgres 7.0.2 compiles great on Solaris 7 and Solaris 8.
> 2) postgres cvs (latest download) doesn't compile (same error on both) on
> Solaris 7 nor Solaris 8.
Ah so. 7.0.*'s configure didn't try t
On Mié 08 Nov 2000 18:01, Tom Lane wrote:
>
> Well, that tells the tale all right: the critical lines are
>
> typedef uint32_tsocklen_t;
>
> typedef void*Psocklen_t;
>
> extern int accept(int, struct sockaddr *, Psocklen_t);
>
> What brainless idiot decided it
"Martin A. Marques" <[EMAIL PROTECTED]> writes:
Is there any kind of info you would need that I could provide?
>>
>> If you could put
>> #include
>> #include
>> into a file temp.c, and then send the output of "gcc -E temp.c",
>> it might shed some light.
> There it goes!!
Well, that tell
[ Charset ISO-8859-1 unsupported, converting... ]
> > > > > New CHECKPOINT command.
> > > > > Auto removing of offline log files and creating new file
> > > > > at checkpoint time.
> >
> > Can you tell me how to use CHECKPOINT please?
>
> You shouldn't normally use it - postmaster will start bac
> > > > New CHECKPOINT command.
> > > > Auto removing of offline log files and creating new file
> > > > at checkpoint time.
>
> Can you tell me how to use CHECKPOINT please?
You shouldn't normally use it - postmaster will start backend
each 3-5 minutes to do this automatically.
> > > Is this t
It has not been officially released yet ... whoever released such did so
pre-maturely ... we don't even have a link to it from the web site yet ...
On Wed, 8 Nov 2000, Trewern, Ben wrote:
> Just thought I'd tell you that ZDNet have announced that v7.0.3 is released!
> Didn't think this was tr
I was able to locate snippets of information regarding the
implementation of an enum column type on a European maillist archive,
but have been unable to locate any addition information regarding this
effort. Could someone be so kind as to pass along an update on this
effort and possibly suggest wh
Title: V7.0.3 Released! - According to ZDNet
Just thought I'd tell you that ZDNet have announced that v7.0.3 is released! Didn't think this was true. If it is did I miss the announcement! If its not ready for release then some people may be using software that they don't know is still in bet
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Thomas Lockhart writes:
>> select int '1' = '01';
>> which, btw, returns 'true'.
> Uh, how can an integer be equal to a character value? Where did the type
> system go?
Nowhere. This is the same behavior as that statement had in 7.0 (and
many vers
Philip Warner <[EMAIL PROTECTED]> writes:
> Where would you store the value if not in pg_database?
No other ideas at the moment. I was just wondering whether there was any
way to delete it entirely, but seems like we want to have the value for
template0 available. The old way of hardwiring know
At 11:13 8/11/00 -0500, Tom Lane wrote:
>
>Do we still need the lastsysoid column in pg_database if we do things
>this way? Seems like what you really want is to suppress all the
>objects that are in template0, so you really only need one lastsysoid
>value, namely template0's. The other entries
Philip Warner <[EMAIL PROTECTED]> writes:
> It would be nice to have a 'supported' COPY DATABASE (which is what we're
> talking about, really), so I'd vote for being able to use any DB as a
> template, if possible.
> Can we restrict the command to databases that have only one active backend?
No
On Thu, Nov 09, 2000 at 02:48:50AM +1100, Philip Warner wrote:
> At 10:15 8/11/00 -0500, Tom Lane wrote:
> >I like
> >
> > CREATE DATABASE foo WITH TEMPLATE 'template0'
> >
> >better than a SET command.
>
> Just seems like we'd be forcing non-standard syntax on ourselves when/if
> CREATE DATA
On Wed, Nov 08, 2000 at 04:05:50PM +0100, Christof Petig wrote:
> Karel Zak wrote:
> >
> > Please, read my old query cache and PREPARE/EXECUTE description...
>
> Sorry I can't find it in my (current) mailbox, do you have a copy around? Or can
> you give me a keyword?
>
In my archives, there's
At 10:56 8/11/00 -0500, Tom Lane wrote:
>Philip Warner <[EMAIL PROTECTED]> writes:
>> Just seems like we'd be forcing non-standard syntax on ourselves when/if
>> CREATE DATABASE becomes CREATE SCHEMA; I would assume that the two
>> statements would become synonymous?
>
>No, I don't think so --- we
Philip Warner <[EMAIL PROTECTED]> writes:
> Just seems like we'd be forcing non-standard syntax on ourselves when/if
> CREATE DATABASE becomes CREATE SCHEMA; I would assume that the two
> statements would become synonymous?
No, I don't think so --- we already have WITH LOCATION and WITH
ENCODING,
At 10:15 8/11/00 -0500, Tom Lane wrote:
>I like
>
> CREATE DATABASE foo WITH TEMPLATE 'template0'
>
>better than a SET command.
Just seems like we'd be forcing non-standard syntax on ourselves when/if
CREATE DATABASE becomes CREATE SCHEMA; I would assume that the two
statements would become
> At 14:04 7/11/00 -0500, Jan Wieck wrote:
>> FWIW, what about having another "template0" database, where
>> nobody can add user data. Initially, template0 and template1
>> are identically. CREATE DATABASE get's a new switch (used by
>> the pg_dump output) that tells to create it from the van
Karel Zak wrote:
> On Fri, 3 Nov 2000, Christof Petig wrote:
>
> > Karel Zak wrote:
> >
> > > On Thu, 2 Nov 2000, Zeugswetter Andreas SB wrote:
> > >
> > > >
> > > > > Well I can re-write and resubmit this patch. Add it as a
> > > > > compile time option
> > > > > is not bad idea. Second possibil
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> What I mean is to change heap_open(r) like
> LockRelationId(Name) -> shared-inval-handling ->
> allocate the relation descriptor and increment rd_refcnt
> This would ensure that relations with rd_refcnt > 0
> acquire some lock. Could any shared-inval
At 14:04 7/11/00 -0500, Jan Wieck wrote:
>> Thoughts? At the moment I'm afraid that the functionality we have is
>> worse than the way prior versions behaved --- not least because anyone
>> who was putting user data in template1 has probably gotten used to the
>> prior behavior. Maybe we should
> > Unfortunately, session 3 with just SELECT * FROM foo will also wait
> > for session 1 & session 2 commit.
>
> Session 3 would wait for session 2 in any case, no?
>
> This is all irrelevant unless someone can make a convincing case that
> it's safe to release read locks early. In the words
> relcache. Not good. Forcing the schema update to be held off in the
> first place seems the right answer.
Agreed, the only question is, how long. My idea would be until statement end,
which is also how Informix does it btw. (If you wanted a prominent example)
Of course a "statement" spans o
> > Will we still have readers-dont-block-writers behaviour?
>
> Sure. The only thing this really affects is VACUUM and schema-altering
> commands, which will now have to wait until reader transactions commit.
And "lock table ...", which would need some deadlock resolution code,
because two se
39 matches
Mail list logo
