> What Philip seems to be asking for is a mechanism where by if a function
> is marked as being mathematically deterministic (given a particular set of
> parameters the same result is always returned -- eg: cos(), sin(),
> etc) then the result is cached and next time the function is called with
>
On Sun, 18 Aug 2002, Joe Conway wrote:
> 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
> Try 'public','s1' perhaps...
Wao, this is confusing:-)
The man page says:
SET variable { TO | = } { value | 'value' | DEFAULT }
And:
test=# show search_path;
search_path
-
public, s1
(1 row)
So user naturally thinks
set search_path to 'public,s1';
is a correct synta
Try 'public','s1' perhaps...
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Tatsuo Ishii
> Sent: Monday, 19 August 2002 2:31 PM
> To: [EMAIL PROTECTED]
> Subject: [HACKERS] set search_path failure
>
>
> I'm seeing this:
>
> test=# create
I'm seeing this:
test=# create schema s1;
CREATE SCHEMA
test=# set search_path to 'public, s1';
ERROR: Namespace "public, s1" does not exist
Am I missing something?
--
Tatsuo Ishii
---(end of broadcast)---
TIP 5: Have you checked our extensive FA
At 22:29 18/08/2002 -0700, Joe Conway wrote:
>create function get_manager_names() returns setof manager_names as
> 'select d.id, p.name from departments d, people p
> where p.id = d.manager_id' language sql;
>
>select p.name, m.name as boss from people p, get_manager_names() m where
>p.d
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
u
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 mov
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
# 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 diffi
There's a couple of new bytea encoding/decoding functions in libpq aren't
there? Or at least there's one...
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Justin Clift
> Sent: Monday, 19 August 2002 7:03 AM
> To: PostgreSQL Hackers Mailing
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 s
[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.
> It might be worth recalling the
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] 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
-
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
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
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
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.
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
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 p
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
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
"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 prob
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
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 user
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. Turnin
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 continu
> > 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 insertion
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 cou
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 "' -
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 turn
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
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 incre
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
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 applica
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
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 sy
38 matches
Mail list logo
