-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Well, unique is usually defined as "not equal to any other". And "not
> equal" also fails transitive law [...]
> But it should be trivial to test at insertion time if the interval
> overlaps with any existing intervals [...]
Putting your point anot
On Sun, 18 Feb 2007, Guillaume Smet wrote:
Hi Oleg,
On 2/17/07, Oleg Bartunov wrote:
3-gram is implemented as a contrib/pg_trgm. It currently uses GiST index,
but may be enhanced with the GiN.
As I'm facing the same problem, I've taken a look to pg_trgm. At the
moment, my opinion is quite m
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Comments, objections? Also, any thoughts about the names to use for
> these new node types? As I commented last year, I'm not completely
> happy with "TopPlan" because it won't actually be a subtype of Plan,
> but I don't have a better idea. Also I'm uns
Mark Kirkwood <[EMAIL PROTECTED]> writes:
> Gavin Sherry wrote:
>> On Sun, 18 Feb 2007, Tom Lane wrote:
>>> Comments, objections? Also, any thoughts about the names to use for
>>> these new node types? As I commented last year, I'm not completely
>>> happy with "TopPlan" because it won't actually
Gavin Sherry wrote:
On Sun, 18 Feb 2007, Tom Lane wrote:
Comments, objections? Also, any thoughts about the names to use for
these new node types? As I commented last year, I'm not completely
happy with "TopPlan" because it won't actually be a subtype of Plan,
but I don't have a better idea
On Sun, 18 Feb 2007, Tom Lane wrote:
> We've repeatedly discussed getting rid of execution-time access to the
> Query structure --- here's one old message about it:
> http://archives.postgresql.org/pgsql-hackers/1999-02/msg00388.php
> and here's a recent one:
> http://archives.postgresql.org/pgsql
While thinking about having a centralized plan cache for managing plan
invalidation, I got annoyed again about the fact that the executor needs
access to the Query tree. This means that we'll be storing *three*
representations of any cached query: raw parsetree for possible
regeneration, plus pars
Gregory Stark wrote:
[snip]
Hm. The set of output columns could change? How?
If you prepare "select *" and add a column, you're saying the query should
start failing? That seems strange given the behaviour of views, which is that
once parsed the list of columns is written in stone. It seems
Tom Lane wrote:
> That is most likely not going to work anyway, because the backend
> operating environment is C not C++. If you dumb it down enough
> --- no exceptions, no RTTI, no use of C++ library --- then it might
> work, but at that point you're really coding in C anyway.
Writing "normal"
On 2/19/07, Tom Lane <[EMAIL PROTECTED]> wrote:
Gregory Stark <[EMAIL PROTECTED]> writes:
> If you prepare "select *" and add a column, you're saying the query should
> start failing?
Either fail or change output; which you like better? The whole point of
this exercise is to support plpgsql fun
Hi Oleg,
On 2/17/07, Oleg Bartunov wrote:
3-gram is implemented as a contrib/pg_trgm. It currently uses GiST index,
but may be enhanced with the GiN.
As I'm facing the same problem, I've taken a look to pg_trgm. At the
moment, my opinion is quite mixed but perhaps I did something wrong.
I ha
Hannu Krosing wrote:
> Ühel kenal päeval, L, 2007-02-17 kell 22:49, kirjutas Chad Wagner:
>
>>
>> However, they don't have vacuum, we do.
>>
>> Right, and I think that is more or less because Oracle doesn't need
>> it. Vacuum's main purpose (correct me if I am wrong) is to
>> recover/mark
Ühel kenal päeval, L, 2007-02-17 kell 22:49, kirjutas Chad Wagner:
>
>
> However, they don't have vacuum, we do.
>
> Right, and I think that is more or less because Oracle doesn't need
> it. Vacuum's main purpose (correct me if I am wrong) is to
> recover/mark rows that are no longer u
Thanks for all your answers,
I begin to study.
Enrico
--
Enrico <[EMAIL PROTECTED]>
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Gregory Stark <[EMAIL PROTECTED]> writes:
> If you prepare "select *" and add a column, you're saying the query should
> start failing?
Either fail or change output; which you like better? The whole point of
this exercise is to support plpgsql functions that do something like
create temp
On Sun, Feb 18, 2007 at 08:14:00PM +0200, Hannu Krosing wrote:
> > but I can promise you you can't make it work with btree.
>
> Sorry to hear that. btree seemed like the best candidate for doing it.
The problem with btree is that it's designed to work with a compare
function which compares two da
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Russell Smith <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> 2. Given a handle for a previously stored query, check to see if the plan
>>> is still up to date; if not, regenerate it from the raw parse tree (note
>>> this could result in failure, eg if a
"Knut P. Lehre" <[EMAIL PROTECTED]> writes:
> After a PQExec with a fetch from a scroll cursor, I only get "FETCH" from
> PQcmdStatus, and not "FETCH count" as described in the 8.2.1 docs. However,
> PQntuples returns the number of fetched rows. If I replace the FETCH by a
> MOVE, PQcmdStatus r
Ühel kenal päeval, L, 2007-02-17 kell 11:26, kirjutas Tom Lane:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > How easy/hard would it be to create unique indexes on tinterval (unique
> > here meaning non-overlapping) ?
>
> "Overlapping" is not an equality relation (it fails the transitive law),
>
Russell Smith <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> 2. Given a handle for a previously stored query, check to see if the plan
>> is still up to date; if not, regenerate it from the raw parse tree (note
>> this could result in failure, eg if a column used by the query has been
>> dropped)
Using libpq with pg 8.2.1 on WinXP Pro SP2.
After a PQExec with a fetch from a scroll cursor, I only get "FETCH" from
PQcmdStatus, and not "FETCH count" as described in the 8.2.1 docs. However,
PQntuples returns the number of fetched rows. If I replace the FETCH by a
MOVE, PQcmdStatus returns "
Alvaro Herrera wrote:
> Peter Eisentraut wrote:
> > Log Message:
> > ---
> > Better fix for determining minimum and maximum int64 values that
> > doesn't require stdint.h and works for "busted" int64.
>
> Nice trick -- is this worth being in c.h or thereabouts?
I was thinking about adding
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
>
> Datum *const_fce(PG_FUNCTION_ARGS)
> {
>text *txt = palloc(5 + VARHDRSZ);
>memcpy(VARDATA(txt), "pavel", 5);
>VARATT_SIZE(txt) = 5 + VARHDRSZ;
>
>PG_RETURN_TEXT_P(txt);
> }
Much better practice is to use the input function of the
On Sun, Feb 18, 2007 at 12:56:08PM -0500, [EMAIL PROTECTED] wrote:
> Hi,
> just for fun, I wrote a little postgresql contrib,
> who has a C function called myfun inside it.
> The function myfun returns a value , now I return
> a cstring type value, and it works fine if
> I run from psql shell:
Y
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
>
> Datum *const_fce(PG_FUNCTION_ARGS)
> {
>text *txt = palloc(5 + VARHDRSZ);
>memcpy(VARDATA(txt), "pavel", 5);
>VARATT_SIZE(txt) = 5 + VARHDRSZ;
>
>PG_RETURN_TEXT_P(txt);
> }
Much better practice is to use the input function of the dat
Hello
cstring is clasic c (zero terminated) string and is used only in some
PostgreSQL functions. This type isn't compatible with text and you have to
explicit cast trick with textin function.
root=# select textin(('abc'::cstring));
textin
abc
(1 row)
Standard is using VARLENA types
Tom Lane wrote:
I'm starting to think about the long-wanted plan invalidation mechanism.
Here's a sketch --- anyone see any problems?
* Create a new module, say src/backend/utils/cache/plancache.c, that we
will put in charge of all long-lived plans --- or at least those cached by
PREPARE, plpgsq
I've sent a message on the subject of 2-byte headers and choice of bitpatterns
twice during the mail outage last night. They may come through eventually but
please ignore them as the situation has changed as new evidence has come to
light.
I was previously doing the second of the two bitpatterns
I've sent a message on the subject of 2-byte headers and choice of bitpatterns
twice during the mail outage last night. They may come through eventually but
please ignore them as the situation has changed as new evidence has come to
light.
I was previously doing the second of the two bitpatterns
I'm currently doing the second of these two proposals:
--- Begin Message ---
Gregory Stark <[EMAIL PROTECTED]> writes:
> In any case it seems a bit backwards to me. Wouldn't it be better to
> preserve bits in the case of short length words where they're precious
> rather than long ones? If we mak
Hi,
just for fun, I wrote a little postgresql contrib,
who has a C function called myfun inside it.
The function myfun returns a value , now I return
a cstring type value, and it works fine if
I run from psql shell:
select value from myfun(paramteres);
but I can't do an insert like:
insert (ch
Added -hackers to CC:.
On 2/18/07, Greg Smith <[EMAIL PROTECTED]> wrote:
I've thought a bit about how to implement this TODO already (I have a log
file parser and I hate maintaining it)
Any problem using pgFouine?
Also, I feel that supporting the whole log_line_prefix syntax for this
feature
Tom Lane wrote:
place. But the question to answer is why the re-plan won't yield
just the same plan as before.
oh and when the estimated cost repeatedly do not match the actual cost,
we of course want to generate an email with all relevant information
that is send to this list ;)
regards,
Tom Lane wrote:
Lukas Kahwe Smith <[EMAIL PROTECTED]> writes:
I remember that there was discussion about invalidating plans who's
estimated cost turn out to be severely off when executed.
That's something we might think about after the infrastructure is in
place. But the question to answer is
34 matches
Mail list logo
