Neil Conway <[EMAIL PROTECTED]> writes:
> Interesting -- I missed that patch, but it seems like a better approach.
> Are you already reviewing Pavel's patch, or is it something I could take
> a look at?
The main objection I have is that I don't think changing the definition
of pg_proc.proargmodes
Hello
It is RETURN TABLE(SQL) via ANSI SQL 2003
Table function support is in patch queue:
http://archives.postgresql.org/pgsql-patches/2007-02/msg00216.php
http://momjian.us/mhonarc/patches/msg1.html
Regards
Pavel Stehule
In a PL/PgSQL set-returning function, returning the result set of
On Mon, 2007-04-23 at 17:48 -0400, Tom Lane wrote:
> I think we've got something isomorphic to that in the patch queue
> already --- take a look at Pavel's "table function" patch. It's in
> need of cleanup but I think it will make it in.
Interesting -- I missed that patch, but it seems like a bet
> > That would be just because you don't know the numbering scheme. 8.2 to
> > 8.3 is considered "major" in these parts. See
> > http://www.postgresql.org/support/versioning
>
> Is that official policy? I don't see any mention of it in the docs.
Are you somehow suggesting that our website isn't
Gregory Stark <[EMAIL PROTECTED]> writes:
> The main data from the statistics that's of interest here are the extreme
> values of the histogram. If we're not interested in any values in that range
> then we can exclude the partition entirely.
Except that there is *no* guarantee that the histogram
The values of pg_enc enumeration are changed between 8.2 and 8.3.
PG_JOHAB was removed and PG_EUC_JIS_2004 was added.
Are there any incompatibility issues here?
For example, if we initialize a server(8.3) using initdb(8.3) and libpq(8.2)
with UTF-8 encoding, the server is actually initialized wit
Hi,
Sorry, because of so many comments/questions, I'll write inline
Josh Berkus wrote:
Hackers,
Writing lots of additional code simply to remove a parameter that
*might* be mis-interpreted doesn't sound useful to me, especially when
bugs may leak in that way. My take is that this is simpl
On Monday 23 April 2007 18:17, Alvaro Herrera wrote:
> That would be just because you don't know the numbering scheme. 8.2 to
> 8.3 is considered "major" in these parts. See
> http://www.postgresql.org/support/versioning
Is that official policy? I don't see any mention of it in the docs.
--
Ro
"Tom Lane" <[EMAIL PROTECTED]> writes:
> For the VALUES case, the suggestion of "row" and "column" terminology
> seems the right thing, but for UNION it would be better to use "branch"
> perhaps ("row" certainly seems misleading). How can we make that work
> without indulging in untranslatable k
Gustavo,
> > Oh, you're talking about distributing partitions across different nodes
> > and parallelizing queries. No, we don't do that today.
>
> Yes.This is the goal. Well, I will try it. I'll send the project
> reports to this list. Comments will be valuable. Desire me good
> luck...
You migh
On 4/23/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
Gustavo Tonini wrote:
> Well, I'm thinking in define (maybe via SQL) a set of servers as a
> cluster and make the fragmentation rules based on "select clauses",
> storing this "configuration" in a specific catalog in global schema.
> For e
Tom Lane wrote:
> For the VALUES case, the suggestion of "row" and "column" terminology
> seems the right thing, but for UNION it would be better to use "branch"
> perhaps ("row" certainly seems misleading). How can we make that work
> without indulging in untranslatable keyword-insertion?
>
> A
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> +1 on using the parser location mechanism and avoiding the
>> terminology problem altogether.
> I figured we would let the parser only point to the UNION or VALUES or
> whatever word. It would be fairly cumbersome to drag the indi
Neil Conway wrote:
> On Mon, 2007-04-23 at 17:38 -0400, Tom Lane wrote:
> > I'm really still opposed to the entire concept. You're proposing to put
> > a lot of fragile-looking code into a seldom-exercised error path.
>
> There's certainly not a "lot" of code: the patch just adds a few
> syscache
Tom Lane wrote:
> +1 on using the parser location mechanism and avoiding the
> terminology problem altogether.
I figured we would let the parser only point to the UNION or VALUES or
whatever word. It would be fairly cumbersome to drag the individual
expression positions down into select_common_
[EMAIL PROTECTED] escribió:
> Josh, List,
>
> On 4/23/07, Josh Berkus <[EMAIL PROTECTED]> wrote:
> >I was thinking about the upcoming release on my 32-hour epic airplane
> >ordeal,
> >and realizing that it changes PostgreSQL in a lot of ways. Between major
> >improvements to performance, major
Tom,
> Eyeing the patch queue and wondering how much of it is really going to
> get in, I'm not sure that eight point two and a half wouldn't be a more
> appropriate name. It's been a short devel cycle and one almost entirely
> focused on performance, not user-visible features.
Ah, in my enthusi
Gregory Stark wrote:
> "Peter Eisentraut" <[EMAIL PROTECTED]> writes:
> > peter=# values(0,1), (1::bigint,2), ('text'::text,3);
> > ERROR: 42804: VALUES types bigint at position 2 and text at
> > position 3 cannot be matched in instance 1
> >
> > I'm not sure about the terminology "position" and "
Tom Lane wrote:
Neil Conway <[EMAIL PROTECTED]> writes:
This works, but it seems overly verbose. It occurred to me that we could
easily add a new PL/PgSQL statement that evaluates a set-returning
expression and adds *all* the resulting rows to the function's result
set. For example:
On Mon, 2007-04-23 at 17:38 -0400, Tom Lane wrote:
> I'm really still opposed to the entire concept. You're proposing to put
> a lot of fragile-looking code into a seldom-exercised error path.
There's certainly not a "lot" of code: the patch just adds a few
syscache lookups, wrapped in a PG_LOCK_
Josh, List,
On 4/23/07, Josh Berkus <[EMAIL PROTECTED]> wrote:
Hackers,
I was thinking about the upcoming release on my 32-hour epic airplane ordeal,
and realizing that it changes PostgreSQL in a lot of ways. Between major
improvements to performance, major changes to the file format, and chan
Josh Berkus <[EMAIL PROTECTED]> writes:
> ... should this be 9.0 instead of 8.3?
No. This is mere version-number-inflation.
Eyeing the patch queue and wondering how much of it is really going to
get in, I'm not sure that eight point two and a half wouldn't be a more
appropriate name. It's bee
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> None of this will help if you have multiple unrelated clauses that
> invoke select_common_type(), but that might be better handled using the
> parser location mechanism.
+1 on using the parser location mechanism and avoiding the terminology
problem
Neil Conway <[EMAIL PROTECTED]> writes:
> This works, but it seems overly verbose. It occurred to me that we could
> easily add a new PL/PgSQL statement that evaluates a set-returning
> expression and adds *all* the resulting rows to the function's result
> set. For example:
I think we've got some
Hackers,
> Writing lots of additional code simply to remove a parameter that
> *might* be mis-interpreted doesn't sound useful to me, especially when
> bugs may leak in that way. My take is that this is simple and useful
> *and* we have it now; other ways don't yet exist, nor will they in time
> f
Neil Conway <[EMAIL PROTECTED]> writes:
> On Sat, 2007-04-21 at 19:43 -0400, Neil Conway wrote:
>> Attached is a very quick hack of a patch to do this.
> Does anyone have any feedback on this approach? If people are satisfied
> with this solution, I can get a cleaned up patch ready to apply shortl
We were about to submit a patch to ECPG to improve the performance
of embedded SQL, when we discovered that PREPARE had quit working.
Background:
We have a benchmark for a very large customer that consists of several
hundred programs containing several thousand embedded SQL statements.
In a thre
Neil,
> This works, but it seems overly verbose. It occurred to me that we could
> easily add a new PL/PgSQL statement that evaluates a set-returning
> expression and adds *all* the resulting rows to the function's result
> set. For example:
>
> RETURN QUERY SELECT ...;
>
> I'm not sure of the
In a PL/PgSQL set-returning function, returning the result set of a
query requires a FOR loop and repeated invocations of the RETURN NEXT
statement:
FOR x in SELECT ... LOOP
RETURN NEXT x;
END LOOP;
This works, but it seems overly verbose. It occurred to me that we could
easily ad
"Peter Eisentraut" <[EMAIL PROTECTED]> writes:
> peter=# values(0,1), (1::bigint,2), ('text'::text,3);
> ERROR: 42804: VALUES types bigint at position 2 and text at position 3
> cannot be matched in instance 1
>
> I'm not sure about the terminology "position" and "instance"; they're
> just two
So I was informed today that UNION types integer and text cannot be
matched. Alright, but it failed to tell which particular expressions
in this 3-branch, 30-columns-each UNION clause in a 100-line statement
it was talking about. So I made the attached patch to give some better
pointers. Exa
On Sat, 2007-04-21 at 19:43 -0400, Neil Conway wrote:
> Attached is a very quick hack of a patch to do this.
Does anyone have any feedback on this approach? If people are satisfied
with this solution, I can get a cleaned up patch ready to apply shortly.
-Neil
---(end of
While poking at Michel Dorochevsky's issue, I noticed that if a DELETE
is done in a table that is referenced by many different foreign keys,
we repeat the ri_Check_Pk_Match test over again for each FK. Seems like
it would be nice to avoid this duplicated work. But right now I don't
see any easy w
Josh Berkus wrote:
Between major
improvements to performance, major changes to the file format, and changes to
implicit conversions breaking backwards compatibility, our new ability to
more-or-less stick to deadlines ...
... should this be 9.0 instead of 8.3?
Seems like it'd be both an ann
All,
You'll notice that the Hyena testing system for Solaris builds is down, due to
an attack and some required system upgrading. Since we'll have the new
Solaris machines up within a few days, I don't plan to revive Hyena's
Buildfarm instance. We're going to put some benchmark code on that m
Hackers,
I was thinking about the upcoming release on my 32-hour epic airplane ordeal,
and realizing that it changes PostgreSQL in a lot of ways. Between major
improvements to performance, major changes to the file format, and changes to
implicit conversions breaking backwards compatibility, o
> > How much effort would it be to add EXPLAIN/EXPLAIN ANALYSE capability to
> > pl/pgsql functions?
> >
> > what I mean, is either a special mode, where "SELECT my_plpgsql_func()"
> > would print all query plans instead or in addition to executing them, or
> > some way for EXPLAIN to pass some fl
On Tue, 2007-04-17 at 16:34 +0300, Marko Kreen wrote:
> Attached patch does following conversions:
ISTM it would be cleaner to use an enum to identify the different
variants of the DISCARD command, rather than a character string.
Is guc.c still the logical place for the implementation of DISCARD?
"Andrew Hammond" <[EMAIL PROTECTED]> writes:
> If you have a table with a bunch of children, and these children all
> have a primary key which is generated from the same sequence, assuming
> that you're partitioning based on date (ie, this is a transaction
> record table), it would be nice if the
If you have a table with a bunch of children, and these children all
have a primary key which is generated from the same sequence, assuming
that you're partitioning based on date (ie, this is a transaction
record table), it would be nice if the planner could spot that all
tables have a primary key
Artur Wasilewski wrote:
Hi,
I was wondering if there is any possibility to add an enhancement in
pgAdmin Query.
Now, when we do "select * from smth", results are listed in DataOutput
tab and there we have columns with the same width (something about
260px currently). It is realy annoying that in
Hi,
I was wondering if there is any possibility to add an enhancement in
pgAdmin Query.
Now, when we do "select * from smth", results are listed in DataOutput
tab and there we have columns with the same width (something about
260px currently). It is realy annoying that in most cases user don't
see
> I don't insist the name and the default of the GUC parameter.
> I'm afraid wal_fullpage_optimization = on (default) makes
> some confusion because the default behavior becomes a bit
> different on WAL itself.
Seems my wal_fullpage_optimization is not a good name if it caused
misinterpretati
Dave Page wrote:
If you want to poke at it, I'd suggest changing the ERROR to PANIC
(it's in bufmgr.c) to cause a core dump, run installchecks till you
get a panic, and then look around in the dump to see what you can find.
Well, in typical fashion after 25+ runs this morning there's not a
fa
Gustavo Tonini wrote:
Well, I'm thinking in define (maybe via SQL) a set of servers as a
cluster and make the fragmentation rules based on "select clauses",
storing this "configuration" in a specific catalog in global schema.
For example: when a record is inserted in a server which not store
this
ITAGAKI Takahiro wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
If I'm reading the code correctly, DSM makes no attempt to keep the
chunks ordered by block number. If that's the case, vacuum needs to be
modified because it currently relies on the fact that blocks are scanned
and the dead
On Mon, 2007-04-23 at 11:01 +0300, Hannu Krosing wrote:
> How much effort would it be to add EXPLAIN/EXPLAIN ANALYSE capability to
> pl/pgsql functions?
>
> what I mean, is either a special mode, where "SELECT my_plpgsql_func()"
> would print all query plans instead or in addition to executing the
Simon Riggs wrote:
On Thu, 2007-04-19 at 22:37 +0200, Florian G. Pflug wrote:
The problem is that after a crash, the master might complete incomplete
actions via rm_cleanup() - but since it won't wal-log those changes,
the slave won't know about this. This will at least prevent the creation
of a
On Thu, 2007-04-19 at 22:37 +0200, Florian G. Pflug wrote:
> I believe I have discovered the following problem in pgsql 8.2 and HEAD,
> concerning warm-standbys using WAL log shipping.
>
> The problem is that after a crash, the master might complete incomplete
> actions via rm_cleanup() - but sin
ITAGAKI Takahiro wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
We might want to call GetCheckpointProgress something
else, though. It doesn't return the amount of progress made, but rather
the amount of progress we should've made up to that point or we're in
danger of not completing the
Zeugswetter Andreas ADI SD wrote:
Hmm, I'll give it a go when I'm back in the office, but bear
in mind this is a Mingw build on which debugging is nigh-on
impossible.
I use the Snapshot
http://prdownloads.sf.net/mingw/gdb-6.3-2.exe?download from sf.net.
It has some issues, but it is definitely
How much effort would it be to add EXPLAIN/EXPLAIN ANALYSE capability to
pl/pgsql functions?
what I mean, is either a special mode, where "SELECT my_plpgsql_func()"
would print all query plans instead or in addition to executing them, or
some way for EXPLAIN to pass some flags to functions so that
> Hmm, I'll give it a go when I'm back in the office, but bear
> in mind this is a Mingw build on which debugging is nigh-on
> impossible.
I use the Snapshot
http://prdownloads.sf.net/mingw/gdb-6.3-2.exe?download from sf.net.
It has some issues, but it is definitely useable.
Andreas
-
53 matches
Mail list logo
