On Mon, 2010-12-27 at 10:36 +0900, Itagaki Takahiro wrote:
> On Mon, Dec 27, 2010 at 02:09, Pavel Stehule wrote:
> > I have a free time and I can do a review of your patch. Please, can
> > send a last version and can send a links on documentation that you
> > used?
>
> Thanks! The latest patch at
On Fri, 2010-12-24 at 23:36 -0500, Robert Haas wrote:
> Here's an updated patch for unlogged tables, incorporating the
> following changes since v4:
Looks good
> 5. Support unlogged GIN indexes.
Not sure from reading the docs whether unlogged indexes are supported on
logged tables? Could you cla
On Thu, 2010-12-23 at 10:53 +0100, Magnus Hagander wrote:
> Here's a patch that changes walsender to require a special privilege
> for replication instead of relying on superuser permissions. We
> discussed this back before 9.0 was finalized, but IIRC we ran out of
> time. The motivation being tha
On Fri, 2010-12-24 at 11:53 +0900, KaiGai Kohei wrote:
> The attached patch is the modular version of SE-PostgreSQL.
Looks interesting.
Couple of thoughts...
Docs don't mention row-level security. If we don't have it, I think we
should say that clearly.
I think we need a "Guide to Security Lab
On Fri, 2010-12-24 at 00:27 -0500, Jie Li wrote:
> I doubt the cost of comparing two integers is the issue here;
> rather
> it's more likely one of how many merge passes were needed.
> You could
> find out instead of just speculating by turning on trace_sor
I got following error when try your advice.
uuid-ossp.c:29:2: ошибка: #error OSSP uuid.h not found
uuid-ossp.c:35:2: ошибка: #error UUID length mismatch
uuid-ossp.c:68:27: ошибка: expected ')' before 'rc'
uuid-ossp.c:83:22: предупреждение: type defaults to 'int' in declaration of
'uuid_t'
uuid-oss
On Mon, Dec 27, 2010 at 09:32, Simon Riggs wrote:
> On Thu, 2010-12-23 at 10:53 +0100, Magnus Hagander wrote:
>
>> Here's a patch that changes walsender to require a special privilege
>> for replication instead of relying on superuser permissions. We
>> discussed this back before 9.0 was finalized
On Mon, Dec 27, 2010 at 9:36 AM, Magnus Hagander wrote:
> Seeing logged SQL isn't - but being able to filter the logfiles on
> that requires a *lot* more than just defining a security privilege. If
> we mean "arbitrary log file reading", the easiest way to fix that
> would be to stop checking for
On Fri, Dec 24, 2010 at 05:46, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> I think I agree with Florian about the confusing-ness of the proposed
>> semantics. Aren't you saying you want NOLOGIN mean "not allowed to
>> log in for the purposes of issuing SQL commands, but
On Mon, 2010-12-27 at 10:36 +0100, Magnus Hagander wrote:
> > Is backup part of this new privilege, or not?
>
> The "integrated base backup", once we have that, that's based on the
> walsender protocol? yes.
> pg_dump style backups? No.
Where does pg_start_backup()/stop fit?
--
Simon Riggs
On Mon, Dec 27, 2010 at 11:34, Simon Riggs wrote:
> On Mon, 2010-12-27 at 10:36 +0100, Magnus Hagander wrote:
>> > Is backup part of this new privilege, or not?
>>
>> The "integrated base backup", once we have that, that's based on the
>> walsender protocol? yes.
>> pg_dump style backups? No.
>
>
On Mon, Dec 27, 2010 at 3:22 AM, Simon Riggs wrote:
> Not sure from reading the docs whether unlogged indexes are supported on
> logged tables? Could you clarify (or clarify more often)? Does this
> solve the hash index situation?
They are not. The only place you'll see that the grammar has been
On Mon, Dec 27, 2010 at 10:53, Magnus Hagander wrote:
> On Fri, Dec 24, 2010 at 05:46, Stephen Frost wrote:
>> * Robert Haas (robertmh...@gmail.com) wrote:
>>> I think I agree with Florian about the confusing-ness of the proposed
>>> semantics. Aren't you saying you want NOLOGIN mean "not allowe
Hello
some quick notes:
* trim_array - you use a deconstruct_array. It unpack all fields and
it could not be effective. Can we limit a unpacked array?
I searched on net. This function has a little bit unconptual name -
DB2 use a synonym for this function array_trim. Can we use this
synonym too?
On Dec27, 2010, at 12:15 , Magnus Hagander wrote:
> Actually, having implemented that and tested it, I realize that's a
> pretty bad idea. For one thing, it broke my own pg_streamrecv program,
> since it requires the ability to connect to the master and select a
> pg_current_xlog_location().
I'm s
Idea is to reduce lock level of ADD/DROP COLUMN from AccessExclusiveLock
down to ShareRowExclusiveLock.
To make it work, we need to recognise that we are adding a column
without rewriting the table. That's a simple test at post parse analysis
stage, but what I can't do is work out whether the col
On Mon, Dec 27, 2010 at 20:15, Pavel Stehule wrote:
> * trim_array - you use a deconstruct_array. It unpack all fields and
> it could not be effective. Can we limit a unpacked array?
Sure, I'll optimize it.
> I searched on net. This function has a little bit unconptual name -
> DB2 use a synony
2010/12/27 Itagaki Takahiro :
> On Mon, Dec 27, 2010 at 20:15, Pavel Stehule wrote:
>> * trim_array - you use a deconstruct_array. It unpack all fields and
>> it could not be effective. Can we limit a unpacked array?
>
> Sure, I'll optimize it.
>
>> I searched on net. This function has a little b
On Mon, 2010-12-27 at 12:00 +0100, Magnus Hagander wrote:
> On Mon, Dec 27, 2010 at 11:34, Simon Riggs wrote:
> > On Mon, 2010-12-27 at 10:36 +0100, Magnus Hagander wrote:
> >> > Is backup part of this new privilege, or not?
> >>
> >> The "integrated base backup", once we have that, that's based o
On Thu, Dec 23, 2010 at 13:09, Magnus Hagander wrote:
> This patch adds counters and views to monitor hot standby generated
> recovery conflicts. It extends the pg_stat_database view with one
> column with the total number of conflicts, and also creates a new view
> pg_stat_database_conflicts that
On Mon, Dec 27, 2010 at 14:25, Simon Riggs wrote:
> On Mon, 2010-12-27 at 12:00 +0100, Magnus Hagander wrote:
>> On Mon, Dec 27, 2010 at 11:34, Simon Riggs wrote:
>> > On Mon, 2010-12-27 at 10:36 +0100, Magnus Hagander wrote:
>> >> > Is backup part of this new privilege, or not?
>> >>
>> >> The "
On Mon, 2010-12-27 at 14:41 +0100, Magnus Hagander wrote:
> >> >
> >> > Where does pg_start_backup()/stop fit?
> >>
> >> Good question :)
> >>
> >> Given that the integrated-base-backup would call it for you, that one
> >> would definitely get it automatically.
> >>
> >> Given that the latest disci
On Mon, Dec 27, 2010 at 14:51, Simon Riggs wrote:
> On Mon, 2010-12-27 at 14:41 +0100, Magnus Hagander wrote:
>> >> >
>> >> > Where does pg_start_backup()/stop fit?
>> >>
>> >> Good question :)
>> >>
>> >> Given that the integrated-base-backup would call it for you, that one
>> >> would definitely
Dne 24.12.2010 13:37, Florian Pflug napsal(a):
> On Dec24, 2010, at 11:23 , Nicolas Barbier wrote:
>
>> 2010/12/24 Florian Pflug :
>>
>>> On Dec23, 2010, at 20:39 , Tomas Vondra wrote:
>>>
I guess we could use the highest possible value (equal to the number
of tuples) - according to
Robert Haas writes:
> or if we go with the some-assembly required version, perhaps:
> "tables do not support %s"
> "views do not support %s"
> "indexes do not support %s"
+1 for that way. Although personally I'd reverse the phrasing:
/* translator: %s is the name of a SQL command */
On Mon, Dec 27, 2010 at 6:42 AM, Simon Riggs wrote:
> Idea is to reduce lock level of ADD/DROP COLUMN from AccessExclusiveLock
> down to ShareRowExclusiveLock.
>
> To make it work, we need to recognise that we are adding a column
> without rewriting the table.
Can you elaborate on why you think t
Magnus Hagander writes:
> On Mon, Dec 27, 2010 at 10:53, Magnus Hagander wrote:
>> We could quite easily make a replication role *never* be able to
>> connect to a non-walsender backend. That would mean that if you set
>> your role to WITH REPLICATION, it can *only* be used for replication
>> and
On Mon, Dec 27, 2010 at 16:33, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Dec 27, 2010 at 10:53, Magnus Hagander wrote:
>>> We could quite easily make a replication role *never* be able to
>>> connect to a non-walsender backend. That would mean that if you set
>>> your role to WITH REP
Robert Haas writes:
> On Mon, Dec 27, 2010 at 6:42 AM, Simon Riggs wrote:
>> Idea is to reduce lock level of ADD/DROP COLUMN from AccessExclusiveLock
>> down to ShareRowExclusiveLock.
>>
>> To make it work, we need to recognise that we are adding a column
>> without rewriting the table.
> Can y
On Mon, 2010-12-27 at 14:54 +0100, Magnus Hagander wrote:
> You will certainly be able to log into the standby with a superuser
> account, nobody is preventing that. This is about protecting the
> *master*. For example, from modifications made by a user who hacked
> the standby.
The users for ma
On Mon, 2010-12-27 at 10:24 -0500, Robert Haas wrote:
> On Mon, Dec 27, 2010 at 6:42 AM, Simon Riggs wrote:
> > Idea is to reduce lock level of ADD/DROP COLUMN from AccessExclusiveLock
> > down to ShareRowExclusiveLock.
> >
> > To make it work, we need to recognise that we are adding a column
> >
On sön, 2010-12-26 at 12:31 -0500, Tom Lane wrote:
> We did clean up C++ keyword uses in the header files in 9.0, but your
> report shows it's already gotten broken again. I'm disinclined to fix
> it unless someone steps up to create an automated test that will get
> run reasonably often. We had
On Mon, Dec 27, 2010 at 16:45, Simon Riggs wrote:
> On Mon, 2010-12-27 at 14:54 +0100, Magnus Hagander wrote:
>
>> You will certainly be able to log into the standby with a superuser
>> account, nobody is preventing that. This is about protecting the
>> *master*. For example, from modifications ma
On Mon, 2010-12-27 at 10:41 -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Dec 27, 2010 at 6:42 AM, Simon Riggs wrote:
> >> Idea is to reduce lock level of ADD/DROP COLUMN from AccessExclusiveLock
> >> down to ShareRowExclusiveLock.
> >>
> >> To make it work, we need to recognise that
Excerpts from Peter Eisentraut's message of lun dic 27 12:54:16 -0300 2010:
> On sön, 2010-12-26 at 12:31 -0500, Tom Lane wrote:
> > We did clean up C++ keyword uses in the header files in 9.0, but your
> > report shows it's already gotten broken again. I'm disinclined to fix
> > it unless someone
Hi everyone,
about two weeks ago I've started a thread about cross-column stats. One
of the proposed solutions is based on number of distinct values, and the
truth is the current distinct estimator has some problems.
I've done some small research - I have read about 20 papers on this, and
I'd lik
Peter Eisentraut writes:
> src/tools/pginclude/cpluspluscheck
Ah, I'd forgotten that.
> What's missing is to automate this, but it's unclear in what context,
> and perhaps also to what extend this should be a hard requirement.
After a bit of experimentation, I can say that this is better than
A
Excerpts from Tom Lane's message of lun dic 27 13:54:56 -0300 2010:
> [ lightbulb ] ... although we could improve that quite a bit if we
> processed each .h file separately instead of insisting on smashing
> everything into one compilation. Let me go try that.
FWIW I have this patch lingering ab
On 12/27/2010 11:54 AM, Tom Lane wrote:
After a bit of experimentation, I can say that this is better than
Andrew's hack, but it's still a good distance shy of something that
should be automated or treated as a hard requirement.
I'm always happy if someone produces something better than I did
On Mon, Dec 27, 2010 at 12:33:00PM -0500, Andrew Dunstan wrote:
> On 12/27/2010 11:54 AM, Tom Lane wrote:
> >After a bit of experimentation, I can say that this is better than
> >Andrew's hack, but it's still a good distance shy of something that
> >should be automated or treated as a hard requirem
On mån, 2010-12-27 at 12:33 -0500, Andrew Dunstan wrote:
> On a more general point, it would be useful to have some
> infrastructure for running quality checks like this and publishing the
> results. We should be way beyond the point where we rely on
> individuals doing this sort of stuff.
I had a
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of lun dic 27 13:54:56 -0300 2010:
>> [ lightbulb ] ... although we could improve that quite a bit if we
>> processed each .h file separately instead of insisting on smashing
>> everything into one compilation. Let me go try that.
> FWIW
On Mon, Dec 27, 2010 at 18:50, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Tom Lane's message of lun dic 27 13:54:56 -0300 2010:
>>> [ lightbulb ] ... although we could improve that quite a bit if we
>>> processed each .h file separately instead of insisting on smashing
>>> everythi
Magnus Hagander writes:
> On Mon, Dec 27, 2010 at 18:50, Tom Lane wrote:
>> src/tools/pginclude/ already contains several scripts for this sort of
>> thing. Bruce runs them by hand occasionally, although I just found out
>> that he's evidently not run the does-each-header-compile-standalone
>> t
BTW, the cpluspluscheck script invokes g++ with -fno-operator-names,
saying
# -fno-operator-names omits the definition of bitand and bitor, which
# collide with varbit.h. Could be fixed, if one were so inclined.
I just confirmed that those two function definitions are the only is
I'm working on a tool to simplify updating the source code of database
functions.
To do a "revert" my plan is to store the values of pg_proc.* before
updating, and then to restore pg_proc for the given oid if a revert is
necessary.
This raises the question,
Is it "safe" to do,
UPDATE pg_proc SET
Simon Riggs writes:
> Do you disagree with the ADD or the DROP, or both?
Both.
> What "stuff" will break, in your opinion? I'm not asking you to do the
> research, but a few curveballs would be enough to end this quickly, and
> leave a good record for the archives.
The most obvious point is tha
On Mon, Dec 27, 2010 at 10:18 AM, Tom Lane wrote:
> Robert Haas writes:
>> or if we go with the some-assembly required version, perhaps:
>
>> "tables do not support %s"
>> "views do not support %s"
>> "indexes do not support %s"
>
> +1 for that way. Although personally I'd reverse the phrasing:
I hope that we don't make the mistake of not checking for collisions
with C++0x keywords, for which GCC 4.3+ has partial support. The new
standard is almost complete, so it will probably become a lot more
relevant soon. There are quite a few new keywords in C++0x, including:
constexpr
decltype
nul
Peter Geoghegan writes:
> I hope that we don't make the mistake of not checking for collisions
> with C++0x keywords, for which GCC 4.3+ has partial support. The new
> standard is almost complete, so it will probably become a lot more
> relevant soon. There are quite a few new keywords in C++0x, i
On 27 December 2010 19:17, Tom Lane wrote:
> [ shrug... ] If it's not a keyword according to popularly available
> tools, then I really have zero interest in worrying about it. This
> is an exercise in making the headers useful in practice, not in academic
> standards conformance.
It isn't acad
On Mon, 2010-12-27 at 13:33 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > Do you disagree with the ADD or the DROP, or both?
>
> Both.
>
> > What "stuff" will break, in your opinion? I'm not asking you to do the
> > research, but a few curveballs would be enough to end this quickly, and
> > l
Excerpts from Peter Geoghegan's message of lun dic 27 16:13:33 -0300 2010:
> I hope that we don't make the mistake of not checking for collisions
> with C++0x keywords, for which GCC 4.3+ has partial support. The new
> standard is almost complete, so it will probably become a lot more
> relevant so
Hello?
Any body here?
I just want to build postgresql from source.
Can you tell me what I doing wrong?
27 декабря 2010 г. 12:28 пользователь Николай Ижиков
написал:
> I got following error when try your advice.
>
> uuid-ossp.c:29:2: ошибка: #error OSSP uuid.h not found
> uuid-ossp.c:35:2: ошибк
Alvaro Herrera writes:
> Excerpts from Peter Geoghegan's message of lun dic 27 16:13:33 -0300 2010:
>> constexpr
>> decltype
>> nullptr
>> static_assert
> I think only constexpr is being currently used from this list, and it's
> easily fixed because it's not exposed beyond a single file.
If you'
Fujii Masao wrote:
> On Fri, Dec 24, 2010 at 11:47 PM, Bruce Momjian wrote:
> > Applied.
>
> storage.sgml seems to need to be updated.
Ah, I see that now, thanks. Patch attached and applied.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterp
*** ** wrote:
> Can you tell me what I doing wrong?
Did you configure --with_ossp_uuid? Did you get any errors or
warnings when you ran ./configure?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgre
=?KOI8-R?B?7snLz8zByiDp1snLz9c=?= writes:
> Hello?
> Any body here?
> I just want to build postgresql from source.
> Can you tell me what I doing wrong?
contrib/uuid-ossp relies on OSSP's uuid library, which you don't seem to
have installed. See
http://www.ossp.org/pkg/lib/uuid/
Most Linux distr
yes. I configure with this flag.
Configure ends successfull.
It print a lot to output so where I have to see for warning messages?
2010/12/27 Kevin Grittner
> *** ** wrote:
>
> > Can you tell me what I doing wrong?
>
> Did you configure --with_ossp_uuid? Did you get any errors or
> war
Yes.
I install ossp-uuid package.
[/usr/src/postgresql-9.0.2] $ ls /usr/lib | grep uuid
drwxr-xr-x 3 root root4,0K Дек 20 22:39 ossp_uuid
-rw-r--r-- 1 root root 17K Авг 2 18:27 libuuid.a
lrwxrwxrwx 1 root root 22 Дек 23 21:35 libuuid.so ->
/usr/lib/libuuid.so.16
lrwxrwxr
Bruce Momjian writes:
> While I am working on pg_ctl, I saw this TODO item:
> Have the postmaster write a random number to a file on startup that
> pg_ctl checks against the contents of a pg_ping response on its initial
> connection (without login)
> This will
On Mon, Dec 27, 2010 at 16:40, Magnus Hagander wrote:
> On Mon, Dec 27, 2010 at 16:33, Tom Lane wrote:
>> Magnus Hagander writes:
>>> On Mon, Dec 27, 2010 at 10:53, Magnus Hagander wrote:
We could quite easily make a replication role *never* be able to
connect to a non-walsender backe
*** ** wrote:
> 2010/12/27 Kevin Grittner
>> Did you configure --with_ossp_uuid? Did you get any errors or
>> warnings when you ran ./configure?
> yes. I configure with this flag.
> Configure ends successfull.
Odd. I don't have the required packages installed (which on my
system wo
Dmitriy Igrishin wrote:
> IMO, it would be better to implement some utility functions to
> make it easy to construct arrays dynamically for PQexecParams
> and PQexecPrepared. This seems to me more universal solution
> and it is useful for both -- high level libpq-libraries authors and for
> those w
"Kevin Grittner" writes:
> *** ** wrote:
>> 2010/12/27 Kevin Grittner
>>> Did you configure --with_ossp_uuid? Did you get any errors or
>>> warnings when you ran ./configure?
>> yes. I configure with this flag.
>> Configure ends successfull.
> Oh, by the way, my copy/paste of the swi
Magnus Hagander writes:
> Updated patch, still pending docs, but otherwise updated: allow
> start/stop backup, make sure only superuser can turn on/off the flag,
> include in system views, show properly in psql.
I'd suggest avoiding creating the static cache variable
AuthenticatedUserIsReplicatio
I'm unable to produce any really "exciting" release notes for alpha3. I
have produced a draft here:
http://wiki.postgresql.org/wiki/Alpha_release_notes_draft Please edit
the bullet points if you have some idea.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
2010/12/27 Tomas Vondra :
> But even though these disadvantages, there really is no other
> way to enhance the estimates. I don't think this should be a
> default behavior - just as in case of cross-column stats this should
> be optional when the current estimator does not work well.
This
On ons, 2010-12-22 at 20:44 +0200, Marko Tiikkaja wrote:
> On 2010-12-22 8:28 PM, Peter Eisentraut wrote:
> > As a side note, I think the term "writable CTE" is a misnomer. The CTE
> > is not writable. The CTE is the result of a write operation.
> >
> > A writable CTE would look like this:
> >
>
On Mon, Dec 27, 2010 at 4:45 PM, Peter Eisentraut wrote:
> I'm unable to produce any really "exciting" release notes for alpha3. I
> have produced a draft here:
> http://wiki.postgresql.org/wiki/Alpha_release_notes_draft Please edit
> the bullet points if you have some idea.
Yeesh. That was
On Mon, Dec 27, 2010 at 22:42, Tom Lane wrote:
> Magnus Hagander writes:
>> Updated patch, still pending docs, but otherwise updated: allow
>> start/stop backup, make sure only superuser can turn on/off the flag,
>> include in system views, show properly in psql.
>
> I'd suggest avoiding creating
Hi all!
Yesterday-today I try to install postgresql, and I have noticed bug in
configure script
If path which you try to install postgresql from, contains "&" symbol, then
configure doesn`t work correctly (it doesn`t make make file)
It writes some thing like this:
config.status: creating GNUmakef
On Mon, Dec 27, 2010 at 4:58 PM, Azat Khuzhin wrote:
> Hi all!
> Yesterday-today I try to install postgresql, and I have noticed bug in
> configure script
> If path which you try to install postgresql from, contains "&" symbol, then
> configure doesn`t work correctly (it doesn`t make make file)
>
On Mon, Dec 27, 2010 at 11:47:14PM +0200, Peter Eisentraut wrote:
> On ons, 2010-12-22 at 20:44 +0200, Marko Tiikkaja wrote:
> > On 2010-12-22 8:28 PM, Peter Eisentraut wrote:
> > > As a side note, I think the term "writable CTE" is a misnomer. The CTE
> > > is not writable. The CTE is the result
I wrote:
> Dan and I have now implemented most of the mitigation techniques
> ..., and I now feel confident I have a good grasp of how long each
> type of data is useful. (By useful I mean that to maintain data
> integrity without them it will be necessary to roll back some
> transactions which
Robert Haas wrote:
> With respect to (b), I think I'd need to see a much more detailed
> design for how you intend to make this work. Off the top of my
> head there seems to be some pretty serious feasibility problems.
I had one random thought on that -- it seemed like a large concern
was tha
"Kevin Grittner" writes:
> Robert Haas wrote:
>> With respect to (b), I think I'd need to see a much more detailed
>> design for how you intend to make this work. Off the top of my
>> head there seems to be some pretty serious feasibility problems.
> I had one random thought on that -- it seem
Tom Lane wrote:
> Well, first, those scans occur only once every few hundred million
> transactions, which is not likely a suitable timescale for
> maintaining statistics.
I was assuming that the pass of the entire table was priming for the
incremental updates described at the start of this th
Dne 27.12.2010 22:46, Robert Haas napsal(a):
> 2010/12/27 Tomas Vondra :
>> But even though these disadvantages, there really is no other
>> way to enhance the estimates. I don't think this should be a
>> default behavior - just as in case of cross-column stats this should
>> be optional wh
It's worth noting that officially (i.e. in the docs), we don't even
call CTEs CTEs at any point. We call them WITH queries. I think that
that's a mistake because we call them CTEs everywhere else.
Is there interest in correcting this, by putting "CTEs" or "Common
table expressions" in parenthesis
Dne 28.12.2010 00:04, Kevin Grittner napsal(a):
> Tom Lane wrote:
>
>> Well, first, those scans occur only once every few hundred million
>> transactions, which is not likely a suitable timescale for
>> maintaining statistics.
>
> I was assuming that the pass of the entire table was priming fo
Peter Geoghegan wrote:
> It's worth noting that officially (i.e. in the docs), we don't even
> call CTEs CTEs at any point. We call them WITH queries. I think
> that that's a mistake because we call them CTEs everywhere else.
>
> Is there interest in correcting this, by putting "CTEs" or "Commo
On Mon, Dec 27, 2010 at 4:21 PM, Bruce Momjian wrote:
> Dmitriy Igrishin wrote:
>> IMO, it would be better to implement some utility functions to
>> make it easy to construct arrays dynamically for PQexecParams
>> and PQexecPrepared. This seems to me more universal solution
>> and it is useful for
On Tue, Dec 28, 2010 at 12:19:47AM +, Peter Geoghegan wrote:
> It's worth noting that officially (i.e. in the docs), we don't even
> call CTEs CTEs at any point. We call them WITH queries. I think that
> that's a mistake because we call them CTEs everywhere else.
Agreed.
> Is there interest i
On Mon, Dec 27, 2010 at 9:28 PM, David Fetter wrote:
> On Tue, Dec 28, 2010 at 12:19:47AM +, Peter Geoghegan wrote:
>> It's worth noting that officially (i.e. in the docs), we don't even
>> call CTEs CTEs at any point. We call them WITH queries. I think that
>> that's a mistake because we call
On Mon, Dec 27, 2010 at 09:51:01PM -0500, Robert Haas wrote:
> On Mon, Dec 27, 2010 at 9:28 PM, David Fetter wrote:
> > On Tue, Dec 28, 2010 at 12:19:47AM +, Peter Geoghegan wrote:
> >> It's worth noting that officially (i.e. in the docs), we don't even
> >> call CTEs CTEs at any point. We cal
to consider libpqtypes for contrib (which we don't have time for atm).
... or as a libpq sibling :)
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postg
, eventually commit
something based on the version attached here.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
fdw-syntax-20101227.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12/27/10 1:45 PM, Peter Eisentraut wrote:
> I'm unable to produce any really "exciting" release notes for alpha3. I
> have produced a draft here:
> http://wiki.postgresql.org/wiki/Alpha_release_notes_draft Please edit
> the bullet points if you have some idea.
I'll see what I can do.
--
On 28 December 2010 01:09, Kevin Grittner wrote:
> Personally, I think it's worth fixing. This sort of disjunction
> between code and documentation can cause confusing for someone
> trying to get started on hacking. It is an exception to the
> otherwise excellent documentation of both the produc
On 12/27/10 7:35 PM, Josh Berkus wrote:
> On 12/27/10 1:45 PM, Peter Eisentraut wrote:
>> I'm unable to produce any really "exciting" release notes for alpha3. I
>> have produced a draft here:
>> http://wiki.postgresql.org/wiki/Alpha_release_notes_draft Please edit
>> the bullet points if you hav
On Tue, Dec 28, 2010 at 03:49:16AM +, Peter Geoghegan wrote:
> On 28 December 2010 01:09, Kevin Grittner wrote:
> > Personally, I think it's worth fixing. This sort of disjunction
> > between code and documentation can cause confusing for someone
> > trying to get started on hacking. It is a
> The simple truth is
>
> 1) sampling-based estimators are a dead-end
While I don't want to discourage you from working on steam-based
estimators ... I'd love to see you implement a proof-of-concept for
PostgreSQL, and test it ... the above is a non-argument. It requires us
to accept that sampl
u Hanada
20101227-psql_dE_doc.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
94 matches
Mail list logo
