Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
I agree 100%. If you want an index, unique constraint, or primary key on
a SERIAL, I think you should explicitly add it. SERIAL should give me a
column that automatically increments -- no more, no less.
Hmm, do you also want to eliminate
Gavin Sherry writes:
In that case, attached is a patch which locates the beginning of the
offending token more efficiently (per your suggestion of using
scanbuf).
In the regression tests there are a couple of cases that could be
improved:
In strings.sql:
-- illegal string continuation
Tom Lane writes:
BTW, I just thought of a small improvement to your patch that eliminates
some of the ugliness. Suppose that when we recognize an attempt to
connect as a global user (ie, feature flag is on and last character of
username is '@'), we strip off the '@' before proceeding.
I'm
Hi,
-- [EMAIL PROTECTED] wrote:
What about checking the input for backslash, quote,
and double quote (\')? If you are not taking care of those in input
then crashing the backend is going to be the least of your worries.
with Perl and *using placeholders and bind values*, the
Hi
-*- Joe Conway [EMAIL PROTECTED] [ 2002-08-18 06:36 ]:
Maybe I should restate my comment above: SERIAL should give me a column
that automatically increments -- no more, no less -- and it should not
allow me to override the value that it gives. Hence an implicit NOT
NULL, but also an
On Sun, 2002-08-18 at 02:35, Joe Conway wrote:
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
I agree 100%. If you want an index, unique constraint, or primary key on
a SERIAL, I think you should explicitly add it. SERIAL should give me a
column that automatically increments -- no
On Fri, 16 Aug 2002, Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian writes:
Socket permissions - only install user can access db by default
unix_socket_permissions in postgresql.conf
This is dead.
Removed, still on TODO.
Daft question but isn't this
Joe Conway [EMAIL PROTECTED] writes:
I know this causes problems for dumped and reloaded data.
Yup.
In MSSQL this
is gotten around by allowing the properties of the data type to be
altered, e.g. in MSSQL you can turn the IDENTITY property on or off
Rather pointless if it can be turned
Peter Eisentraut [EMAIL PROTECTED] writes:
In strings.sql:
-- illegal string continuation syntax
SELECT 'first line'
' - next line' /* this comment is not allowed here */
' - third line'
AS Illegal comment within continuation;
ERROR: parser: parse error at or near ' - third line'
Peter Eisentraut [EMAIL PROTECTED] writes:
I'm concerned that we leave essentially no migration path, that is, the
ability to turn the feature on to try it out without immediately breaking
every application.
Uh ... what? I fail to understand your objection. AFAICS the only
apps that could
In MSSQL this
is gotten around by allowing the properties of the data type to be
altered, e.g. in MSSQL you can turn the IDENTITY property on or off
Rather pointless if it can be turned off, wouldn't you say?
What I would do if I wanted such a guarantee is to make insertions
go
On Sun, 18 Aug 2002, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
In strings.sql:
-- illegal string continuation syntax
SELECT 'first line'
' - next line' /* this comment is not allowed here */
' - third line'
AS Illegal comment within continuation;
ERROR:
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
In MSSQL this
is gotten around by allowing the properties of the data type to be
altered, e.g. in MSSQL you can turn the IDENTITY property on or off
Rather pointless if it can be turned off, wouldn't you say?
Not really. Turning it off
On Sat, 17 Aug 2002, Bruce Momjian wrote:
OK, I think we are doing this backwards. Instead of adding '@' to
global users, and then removing it in the backend, why don't we have
local users end with '@', that way, global users continue to connect
just as they have before, and local users
On Sat, 17 Aug 2002, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, I think we are doing this backwards. Instead of adding '@' to
global users, and then removing it in the backend, why don't we have
local users end with '@', that way, global users continue to connect
just
Nigel J. Andrews [EMAIL PROTECTED] writes:
Daft question but isn't this an administrator's issue?
The feature wasn't going to change; the argument was just about whether
to change the factory-default permissions mask for the socket. An admin
could override the default in any case (and probably
Rod Taylor wrote:
In MSSQL this
is gotten around by allowing the properties of the data type to be
altered, e.g. in MSSQL you can turn the IDENTITY property on or off
Rather pointless if it can be turned off, wouldn't you say?
What I would do if I wanted such a guarantee is to make insertions
Gavin Sherry [EMAIL PROTECTED] writes:
Reworking the code to taken into account token_start seems to work.
Yes, I did that last night ...
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive
Marc G. Fournier writes:
Okay, here is what I'd like to suggest ... Bruce, let's start off really
simple ... go create a project for libpq++ (I believe someone even
volunteered to maintain it?) and let me know once created, and I'll move
the CVS directory over for libpq++ and out of the
Tom Lane writes:
Character 1 is correct as of the context that the parser is working
in, namely the function body. I don't think we can do much to change
that, but perhaps we could make the message read like
ERROR: parser: parse error at or near not at character 1 of function body
That
Tom Lane writes:
Peter Eisentraut [EMAIL PROTECTED] writes:
I'm concerned that we leave essentially no migration path, that is, the
ability to turn the feature on to try it out without immediately breaking
every application.
Uh ... what? I fail to understand your objection. AFAICS the
Peter Eisentraut [EMAIL PROTECTED] writes:
I'm completely lost between all the proposals about where the @ is going
to be specified, added, or removed. What happens on the client side and
what happens on the server side?
Well, the way things stand as of CVS tip is that (assuming you have
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
Character 1 is correct as of the context that the parser is working
in, namely the function body. I don't think we can do much to change
that, but perhaps we could make the message read like
ERROR: parser: parse error at or near
I'm trying to make postGIS work with pg7.3devel. But a problem is occuring that did
not appear in pg7.2. When I execute:
ALTER TABLE geotest ADD CHECK ( geometrytype(geopoint)='POINT'
OR NULL=geopoint);
I get: ERROR: copyObject: don't know how to copy node type 506
But when I execute:
ALTER
[EMAIL PROTECTED] writes:
I get: ERROR: copyObject: don't know how to copy node type 506
This is a bug in someone's recent patch ... but you don't want to say
NULL=geopoint anyway, do you? Surely it should be geopoint IS NULL.
regards, tom lane
Hi everyone,
Conni is the author of a German PostgreSQL book, and is also a member of
the PHP documentation team.
She's updating some parts of the official PHP manual at present, an
she'll be up to the PostgreSQL section pretty soon.
Does anyone have stuff they'd like to see included, etc?
[EMAIL PROTECTED] (Tom Lane) wrote
* If a connection request has a username with a trailing '@' (and no
embedded '@'), then the '@' is stripped and connection proceeds.
* Otherwise, '@dbname' is appended to the given username and
connection proceeds.
snip
It might be worth recalling the
I've just noticed that a bunch of places use strVal() to access the name
field of an Ident node. (Try changing strVal() to
#define strVal(v)(AssertMacro(IsA(v, String)), ((Value *)(v))-val.str)
and watch the fur fly...)
This works, at the moment, because Ident and Value nodes have a
# Disallow TRUNCATE on tables that are involved in referential
constraints
The above is on the TODO list. Are there any thoughts as to what we
want to do with this? The patch I submitted earlier received heavy
feedback saying it wasn't wanted due to rules and triggers (foreign
keys) being
OK - I assume from everybody else's silence that they either (a) agree with
the idea, or (b) think Tom hit the idea on the head, so they feel they
don't need to respond.
So what I would like to do is implement a simple version of this to attempt
to justify my claims of performance gains. The
On Sun, 18 Aug 2002, Peter Eisentraut wrote:
Marc G. Fournier writes:
Okay, here is what I'd like to suggest ... Bruce, let's start off really
simple ... go create a project for libpq++ (I believe someone even
volunteered to maintain it?) and let me know once created, and I'll move
the
Philip Warner wrote:
So the obvious question is - in the opinion of people who know the code,
can a function-result-cache be implemented with a lifetime of a single
statement, without butchering the function manager?
I don't know if I fully understand what you're proposing, but if I
32 matches
Mail list logo
