On Fri, Mar 21, 2003 at 04:33:09PM +0100, Christoph Haller wrote:
> >
> > Hmm, maybe the transformation in the other direction is the culprit.
> > What I do is call ts1 = PGTYPEStimestamp_atot("2000-7-12 17:34:29",
> NULL); followed by a text = PGTYPEStimestamp_ttoa
> (ts1); Needless to say the res
>From what I can see the sequence name is not changed when you rename a
table
test=# alter table fooseq rename to fooseq1;
ALTER TABLE
test=# \d fooseq1
Table "public.fooseq1"
Column | Type | Modifiers
+-+-
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Doesn't this duplicate a function that we already invented for PQnotify
> >> structs?
>
> > What do you recommend? Do we depricate PQfreeNotify?
>
> I dunno. In hindsight it was shortsightedly named. But I don
No response on general to my sort of esoteric question...
Any info here on hackers?
--elein
-- Forwarded Message --
Subject: [GENERAL] statement id
Date: Tue, 18 Mar 2003 19:03:35 -0800
From: elein <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Is there any w
Tom Lane writes:
> I had originally been thinking of reporting client_encoding as a field
> of some message sent only at backend startup. However, what if we send
> such a message whenever one of the variables it includes changes?
The silent assumption behind the client_encoding parameter is tha
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Tom Lane wrote:
> > >> Doesn't this duplicate a function that we already invented for PQnotify
> > >> structs?
> >
> > > What do you recommend? Do we depricate PQfreeNotify?
> >
> > I dunno. In hindsight
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Do we really want "PQfreemem" either? Maybe it should be "PQfree"?
> I am a little concerned that PQfree would be confused with PQclear.
Good point --- nevermind that suggestion.
> Could we have PQfreeNotify() be a macro to PQfreemem in 7.4?
I'd lik
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Do we really want "PQfreemem" either? Maybe it should be "PQfree"?
>
> > I am a little concerned that PQfree would be confused with PQclear.
>
> Good point --- nevermind that suggestion.
>
> > Could we have PQfreeNotify() be a mac
elein wrote:
Is there any way to find out the statement context in a server function?
Is there anyway to find out the transaction context in a server function?
[...snip...]
If this were a C function, would it be easier to have this information?
I don't know anything about plpython, but I'd guess t
While messing around in gram.y I came across a production like this:
| a_expr IS OF '(' type_list ')' %prec IS
{
$$ = (Node *) makeSimpleA_Expr(AEXPR_OF, "=", $1, (Node *) $5);
}
| a_expr IS NOT OF '(' type_list ')' %prec IS
{
$$ = (Node *) makeSimpleA_Expr(AEXPR_OF, "!=", $1, (Node *) $6);
}
Joe Conway <[EMAIL PROTECTED]> writes:
> Pretty handy! But I couldn't find it documented anywhere -- is it?
I think Thomas did that in one of his last batches of changes, and then
disappeared without adding the documentation. Feel free to contribute
some.
I believe it is supposed to be a SQL99 f
Yes, this is exactly what I'm looking for. I was
hoping the connection context information might be
available in one of the stat tables, some SQL variable
or function call.
The ability to have data persist across function calls
without having to resort to C is really very useful,
but having so
On Sat, 22 Mar 2003, Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
> > Pretty handy! But I couldn't find it documented anywhere -- is it?
>
> I think Thomas did that in one of his last batches of changes, and then
> disappeared without adding the documentation. Feel free to contribute
Gavin Sherry wrote:
8.14 to be exact.
8.18 in SQL200x. I don't think the current implementation quite meets
the spec however:
regression=# select f2 is null, f2 is of(int) from bar;
?column? | ?column?
--+--
f| t
t| t
(2 rows)
If I read the spec correctly, the
On Fri, 2003-03-21 at 17:38, Tom Lane wrote:
> AFAICS, our CVS-tip behavior is a reasonable superset of the spec.
> We don't have the "NO SCROLL" noiseword (which was not in SQL92 anyway),
> but otherwise I'm happy with what's there now.
Yeah, I guess there's no need to actual enforce NO SCROLL --
Neil Conway <[EMAIL PROTECTED]> writes:
> In other words, who is *actually* going to specify NO SCROLL, and then
> expect to scroll the cursor? I'd say just about no one, intentionally --
Well, if you want to do a three-way switch as per earlier discussion,
I won't object. I can't get real excite
Andreas Pflug <[EMAIL PROTECTED]> writes:
> PostgreSQL 7.3.2
> CREATE DOMAIN testdom AS int4;
> CREATE TABLE testtab(testcol testdom);
> INSERT INTO testtab VALUES (1);
> INSERT INTO testtab VALUES (2);
> VACUUM ANALYZE testtab;
> SELECT * FROM testtab WHERE testcol > 1;
I've applied a patch to f
Here's a fun one: in 7.3 or CVS tip, try
regression=# create domain tint as int;
CREATE DOMAIN
regression=# select 1::tint > (-1);
?column?
--
t
(1 row)
regression=# select 1::tint > (-1)::tint;
?column?
--
f
(1 row)
How's that again? Well, when you dig into it you find th
Bruce Momjian <[EMAIL PROTECTED]> writes:
> The problem with that is the new versions are still going to reference
> PQfreeNotify, and then we still can't remove it. I think we need the
> macro for PQfreeNotify pointing to PQfreemem, but keep the PQfreeNotify
> function around for a release or two,
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The silent assumption behind the client_encoding parameter is that you
> must set it to the actual character set encoding used by the client. If
> you lie, the results are unspecified. So if you're in a JDBC application
> and set the client encoding
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > The problem with that is the new versions are still going to reference
> > PQfreeNotify, and then we still can't remove it. I think we need the
> > macro for PQfreeNotify pointing to PQfreemem, but keep the PQfreeNotify
> > function ar
I wrote:
>> I think that we can actually get away (from an implementation point of
>> view) with a column containing arrays of different base types; array_out
>> will still work AFAIR. It's an interesting question though how such a
>> column could reasonably be declared. This ties into your recen
22 matches
Mail list logo
