s different approaches, and if you like what we are doing
you can certainly participate in the development.
http://gborg.postgresql.org/project/pgreplication/projdisplay.php
Regards
Darren
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
e is
potential for a dead lock across system boundary in this
example. If the pre commit messages were sent at the same
time which server would lock the resource?
Darren
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
to queue/log writesetswith postgres-r, so we can
have multi-master replication
and PITR from the same mechanism.
Darren
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
oks like a modified version of the old BSD license
> where you are required to mention you are using Spread. I believe we
> can get that reduced. (I think Darren already addressed this with
> them.) We certainly are not going to accept software that requires all
> PostgreSQL
, and having problems,
but I don't recall investigating what the problems were.
If you still have the code I can try and reproduce the
problem, and investigate it on the spread list.
Darren
---(end of broadcast)---
TIP 2: you can get
don't know
> enough about replication so I will let you fight it out with him. ;-)
>
If were still defining synchronous as pre commit, then
postgres-r is synchronous.
Darren
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
>
>
> Darren, can you clarify this? Why does it send that message? How does
> it allow commits not to wait for ordered writesets?
>
There are two channels. One for total order writesets
(changes to the DB). The other is simple order for
aborts, commits, joins (systems join
> Not the code, just Darren' pdf ("slide show" -:()
> and discussion in hackers' list.
>
You might want to read this paper. Its not very long, and
will give you much more insite on the postgres-r work.
http://www.cs.mcgill.ca/~kem
>
> I'm trying to port some replication code from 7.2 -> 7.4 and am running
> into a block.
>
> In the file:
> /src/backend/tcop/postgres.c
>
Sorry I'm not answering your question, but I didn't have a
chance to look last night. Di
On 2013.08.27 7:57 PM, Tom Lane wrote:
Darren Duncan writes:
I have a proposal.
Assuming we decide to do away with RULEs,
You lost me already.
If we had replacement functionality for everything that can be done with
rules, we could start to think about when we might begin to tell people
ll try and answer as time permits.
-- Darren Duncan
On 2013.05.11 9:27 AM, Tom Lane wrote:
David Fetter writes:
On Sat, May 11, 2013 at 11:17:03AM -0400, Robert Haas wrote:
Some kind of extendable parser would be awesome. It would need to tie
into the rewriter also.
No, I don't have a c
Would that not work? -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
implicitly stringify. But I can also accept implicit
stringification / language behavior changes if it is a lexical/temporary effect
that the same user is still explicitly turning on.
-- Darren Duncan
Jeff Davis wrote:
On Mon, 2012-12-10 at 14:07 -0500, Robert Haas wrote:
And we not only don&#
, meaning ones that can
work with any relations like built-ins can, and the ability to iterate over
record fields, or at least introspect a relation to see what fields it has, is a
good foundation to support this. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
se that to
represent some things in a more natural manner than a tabular format? JSON is
designed to be machine-parseable, and some objects such as routine definitions
are naturally trees of arbitrary depth. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
can
exist in order to support implementation matters of foreign keys that require
their targets to be unique.)
How much work would it be to support this? But also important, does anyone
either agree it should be supported or does anyone want to counter-argue that it
shouldn't be supp
On 2013.03.25 1:17 AM, Albe Laurenz wrote:
Darren Duncan wrote:
From my usage and
http://www.postgresql.org/docs/9.2/interactive/sql-createtable.html I see that
Postgres requires constraints like unique (and primary) keys, and foreign keys,
to range over at least 1 attribute/column.
I
7;t
any actual loss of functionality, but users might have to change their code to
do it "the one true way", that would seem a good thing. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2013.03.25 6:03 PM, Darren Duncan wrote:
On 2013.03.25 5:55 PM, Craig Ringer wrote:
On 03/25/2013 10:28 PM, Tom Lane wrote:
Yeah, they are, because things break when they're set wrong.
They also make debugging and support harder; you need to get an
ever-growing list of GUC values fro
On 2013.03.26 1:40 AM, Albe Laurenz wrote:
Darren Duncan wrote:
So, determining if 2 rows are the same involves an iteration of dyadic logical
AND over the predicates for each column comparison. Now logical AND has an
identity value, which is TRUE, because "TRUE AND p" (and &
. Are drops the main expected use case for the feature,
rather than "tell me when something happened"? -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2013.05.09 11:22 AM, Alvaro Herrera wrote:
Darren Duncan wrote:
On 2013.05.09 10:40 AM, Pavel Stehule wrote:
I am writing a article about 9.3. I found so event trigger functions is not
complete. We have only pg_event_trigger_dropped_objects() function. It looks
really strange and asymmetric
That sounds like a good change to me. -- Darren Duncan
Craig Ringer wrote:
Hi all
I'm seeing lots of confusion from people about why:
REVOKE CONNECT ON DATABASE foo FROM someuser;
doesn't stop them connecting. Users seem to struggle to understand that:
- There's a d
arly, all the converting operators between other types
and JSON would be with #2 only, and producing #1 must go through #2.
So call #1 say JSON_source and #2 say JSON_model, or JSON_text and JSON
respectively.
That's how I think it should work.
-- Darren Duncan
--
Sent via pgsql-
delay #1 is if we aren't sure we're going to go ahead
with it, and give a few months to think about it before announcing this major
thing suddenly. Waiting until 9.3 just to make an announcement is silly.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
, and it will alert users right where they're
most likely to look, the RULEs documentation, without any undue delay.
How does that sound?
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
have used it.
(Though all database access would be over a private server-server network, so
the situation isn't as bad as going over the public internet.)
How much trouble would it be to make the
http://www.postgresql.org/download/linux/redhat/ packages include SSL?
-- Darren Dunc
John R Pierce wrote:
On 10/12/12 9:00 PM, Darren Duncan wrote:
And now we're migrating to Red Hat for the production launch, using
the http://www.postgresql.org/download/linux/redhat/ packages for
Postgres 9.1, and these do *not* include the SSL.
hmm? I'm using the 9.1 for CentO
any
triggers, as if it were just a syntactic shorthand. Or alternately/also provide
extra syntax to TRUNCATE itself where one can specify which behavior to have,
and both options can be given explicitly to override any config option.
-- Darren Duncan
--
Sent via pgsql-hackers m
vileges.
Thank you.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Dimitri Fontaine wrote:
Darren Duncan writes:
So, I'm partly proposing a specific narrow new feature, "TRUNCATE FOR EACH
ROW"
Kevin has been proposing that we consider an alternative approach in
some other cases that I think would work better for you, too. Namely, to
have ac
ero tuples.
Jeff, I get the impression your proposal is partly about helping performance by
supporting this internally, rather than one just defining it as a SQL function,
am I right?
-- Darren Duncan
Jeff Davis wrote:
I hope this is not an inappropriate time for 9.3 discussions. The fli
have different interpretations in the
transform.
Ideally the feature would also work not only for interfacing with PLs but also
with client languages, since conceptually its alike but just differing on who
calls who.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
able, so it has a corresponding type like the regular
table/relation-typed variables in the database.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
DBMS being given only
the view-defining SELECT, where possible. -- Darren Duncan
Dean Rasheed wrote:
I've been playing around with the idea of supporting automatically
updatable views, and I have a working proof of concept. I've taken a
different approach than the previous attempts to
n also use a new constant syntax (unless you have one?) to
allow a routine to invoke itself without knowing its own name, which could be
nice in a simple recursive routine. Maybe ".(arg,arg)" would do it?
I would think this should be non-intrusive and useful and could go in 9.1.
-- D
Robert Haas wrote:
On Sep 8, 2010, at 3:17 PM, Darren Duncan wrote:
Bruce Momjian wrote:
Sergey Konoplev wrote:
3.
CREATE FUNCTION func_very_very_very_very_long_name() RETURNS integer AS $$
<< func_alias >>
DECLARE
var_name text := 'bla';
BEGIN
RAISE INFO &#
Alvaro Herrera wrote:
Excerpts from Darren Duncan's message of mié sep 08 17:41:40 -0400 2010:
For example, if it wouldn't conflict with anything, one could use the "|" symbol
(mnemonic is that means "alternation" in regular expressions) l
Alvaro Herrera wrote:
Excerpts from Darren Duncan's message of mié sep 08 18:29:35 -0400 2010:
Personally I like the idea of developers not always having to be forced to
choose among two equally good names, and making a wrapper function would be
overkill for this feature.
While I
ading the
meaning of the FUNCTION keyword, like what a C function or a Perl sub does,
where returning VOID means procedure, then what is being added by a distinct
PROCEDURE? Or is the VOID-returning FUNCTION going to be deprecated or
discouraged at the same time?
-- Darren Duncan
--
Sent
Tom Lane wrote:
Darren Duncan writes:
Since Pg's FUNCTION already seems to take on both roles, so overloading the
meaning of the FUNCTION keyword, like what a C function or a Perl sub does,
where returning VOID means procedure, then what is being added by a distinct
PROCEDURE?
You
that it stays in the restrictions of #1 or #2. But if not, then I
think it would be valuable to do so, for assisting reliability and performance.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
like about SQL contrasted with typical other
languages is in how query results are typically returned "out of band" like the
above describes, rather than explicitly either via an OUT/INOUT parameter or as
a function result relation value. -- Darren Duncan
--
Sent via pgsql-hackers mail
Peter Eisentraut wrote:
On tor, 2010-09-09 at 13:08 -0700, Darren Duncan wrote:
Since Pg's FUNCTION already seems to take on both roles, so
overloading the meaning of the FUNCTION keyword, like what a C
function or a Perl sub does, where returning VOID means procedure,
then what is being
to implement an activity log, so some kind of IPC would be
going on.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas wrote:
On Wed, Sep 15, 2010 at 2:32 PM, Darren Duncan wrote:
The point being, the answer to how to implement autonomous transactions
could be as simple as, do the same thing as how you manage multiple
concurrent client sessions, more or less. If each client gets its own
Postgres
stand either "a0" or "rv" getting a
substitution, but something following an "AS" being substituted is just wrong.
Is that a bug and if not then what is the rationale for working that way, and
can it be changed?
Meanwhile, what is the best way to write f to work around th
variable. But
no worries; Heikki/Andrew/Alvaro understood what I meant.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ay to do object-relational databases, given that
pure functions and immutable data structures are typically the best way to
express anything one would do with them. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
ed at all by the delay in
migrating repositories while the CVS is cleaned up? -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
aybe to test if a value can be cast as a type, you can continue the ::
mnemonic, say adding a "?" for yes and a "!" for no.
For example, "?::" tests if the value can be cast as the type
and "!::" or "not ?::" tests the opposite.
An expression li
Craig Ringer wrote:
On 25/09/2010 11:51 AM, Darren Duncan wrote:
There should just be a single syntax that works for all types, in the
general case, for testing whether a value is a member of that type, or
alternately whether a value can be cast to a particular type.
Pg already gets it right
ntifiers whatever is most suitably descriptive for them without
worrying whether the language has a pre-defined meaning for the used words.
The quoting also has the nice bonus of making them case-sensitive.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
rsing should be easier, too, because keywords formatted like this would just
be a single term rather than having infinite variations due to embedded whitespace.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
Andrew Dunstan wrote:
On 09/28/2010 09:31 PM, Darren Duncan wrote:
Code that quotes all of its identifiers, such as with:
FOR EACH "var" IN "array_expr" LOOP ...
This doesn't help in the least if the array is an expression rather than
simply a variable - we'
er pragma synchronous=normal or synchronous=full should be the default, and
thankfully 'full' won.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
d the
catalog so it represents all the details you want to preserve. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
QL updates go to postgresql.conf.auto, which consists only of
"setting = value" in alphabetical order.
(d) We document that settings which are changed manually in
postgresql.conf will override postgresql.conf.auto.
(e) $$profit$$!!
I agree that this looks like an effective solutio
ing would only appear in the catalog
if specially formatted, which for now could just mean taking end-of-line comments.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
s data fields in their runtime-accessible objects.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
, loosely speaking.
The association of a multiset-typed attribute of a table with said table is like
the association of a child and parent table in a many-to-one.
So reuse your structure for tables to hold multisets.
-- Darren Duncan
Itagaki Takahiro wrote:
Postgres supports ARRAY data types well
or ?) etc was so that SQL could
be written in EBCDIC which natively lacks some of the bracketing characters that
ASCII has. Hence, such is an alternative way to spell either { } or [ ] (I
forget which).
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
f my identifiers as being case-sensitive. Knowing that
Pg treats non-delimited identifiers as being lowercase, I write undelimited when
the identifier is entirely lowercase, and I delimit ones that have any
uppercase. And by doing this consistently everything works correctly. Since
most of my ident
there was/is a lot I still didn't/don't know about
Postgres, I have found that as I use and learn Postgres, I'm finding frequently
that how Postgres does things is similar and compatible to how I independently
came up with Muldis D's design; I'm finding more similariti
Daniel Farina wrote:
On Sat, Nov 13, 2010 at 7:54 PM, Darren Duncan wrote:
You don't have to kludge things by implementing arrays as blobs for example;
you can implement them as relations instead. Geospatial types can just be
tuples. Arrays of structured types can just be relations wi
should be
deterministic. But that ship has sailed and I'm not going to argue for any
changes to functions.)
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
a
regular transaction or savepoint or whatever is specific to a process/auto.
Has anyone else thought of the DBMS as operating system analogy? I don't recall
specifically reading this anywhere, but expect the thought may be common.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list
just a type constraint and an optimization.
Of course, when we know the type of a column/etc isn't going to be VARIANT or
some other union type, then a simple optimization allows us to just store the
value and have its type provided by context rather than the struct.
-- Darren Duncan
--
Thanks for picking up on my mentioning union types; I wasn't sure if anyone did.
Merlin Moncure wrote:
On Fri, May 6, 2011 at 3:18 PM, Andrew Dunstan wrote:
On 05/06/2011 04:08 PM, Alvaro Herrera wrote:
Excerpts from Darren Duncan's message of mié may 04 15:33:33 -0300 2011:
I s
ncept from what we're otherwise
talking about as being union types. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alvaro Herrera wrote:
Excerpts from Bruce Momjian's message of mar may 10 16:21:36 -0400 2011:
Darren Duncan wrote:
To follow-up, an additional feature that would be useful and resembles union
types is the variant where you could declare a union type first and then
separately other
Robert Haas wrote:
On Wed, May 11, 2011 at 11:43 AM, Joseph Adams
wrote:
On Tue, May 10, 2011 at 5:19 PM, Darren Duncan wrote:
Examples of open union types could be number, which all the numeric types
compose, and so you can know say that you can use the generic numeric
operators on values
ld be supported in tables too.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
asier for users to predict what behavior will occur, and
implementation will be easier too.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Darren Duncan wrote:
I think it would be best that the generic cast syntax only be useable
for casts defined on the base type, and if you want a domain-specific
one you should use the function syntax such as your datetime2int().
That way it is easier for users to predict what behavior will
Jaime Casanova wrote:
On Sat, May 14, 2011 at 8:42 PM, Darren Duncan wrote:
First of all, what if "cast(timestamp as int)" was already defined? Which
cast then would you expect to be invoked here?
'1800-01-01 00:00:00'::int
i will expect an error in that case... what y
o2bar() function instead. You still get code with the same level of
terseness and that is just as easy to read and understand, and there is no
question of semantics. Also, that solution works right now. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
overlap period where people could get the legacy add-ons either way.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas wrote:
On Tue, May 17, 2011 at 4:45 PM, Joshua D. Drake wrote:
On 05/17/2011 01:31 PM, Darren Duncan wrote:
I have missed it if this was discussed before but ...
Would now be a good time to start deprecating the contrib/ directory as
a way to distribute Pg add-ons, with favor
general results of range union operations.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Pavel Stehule wrote:
2011/6/6 Darren Duncan :
Jeff Davis wrote:
I'd like to take another look at Range Types and whether part of it
should be an extension. Some of these issues relate to extensions in
general, not just range types.
First of all, what are the advantages to being in core?
Jeff Davis wrote:
On Sun, 2011-06-05 at 21:51 -0700, Darren Duncan wrote:
Jeff Davis wrote:
I'd like to take another look at Range Types and whether part of it
should be an extension. Some of these issues relate to extensions in
general, not just range types.
First of all, what ar
r finds that 2 operands to the generic "=" (equality test) operator
result in TRUE, then the program should feel free to replace all occurrences of
one operand in the program with occurrences of the other, for optimization,
because generic "=" returning TRUE means one is just
Jeff Davis wrote:
On Mon, 2011-06-06 at 14:42 -0700, Darren Duncan wrote:
Can Pg be changed to support "." in operator names as long as they don't just
appear by themselves? What would this break to do so?
Someone else would have to comment on that. My feeling is that
ons on those
values (such as sorting) should be considered part of the data type of those values.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to text/etc types is the root of the problem. The
range-specific stuff can remain ANYELEMENT and no special-casing is required.
Also, besides range constructors, a generic membership test like "value in
range" is polymorphic. -- Darren Duncan
--
Sent via pgsql-hackers mailing list
Florian Pflug wrote:
On Jun20, 2011, at 20:58 , Tom Lane wrote:
Darren Duncan writes:
I still think that the most elegant solution is for stuff like collation to just
be built-in to the base types that the range is ranging over, meaning we have a
separate text base type for each text
nd hence you'd rarely see any 'foo'::text__en_US
for example. You'd more likely see the less common var::text__en_US or such.
So that's my position, CREATE TYPE on the regular types or the like is the best
solution, and anything else is an inferior solution.
Such a d
Tom Lane wrote:
Darren Duncan writes:
I believe that the best general solution here is for every ordered base type to
just have a single total order, which is always used with that type in any
generic order-sensitive operation, including any ranges defined over it, or any
ORDER BY or any
Jeff Davis wrote:
On Sun, 2011-06-26 at 00:57 -0700, Darren Duncan wrote:
I believe that the best general solution here is for every ordered base type to
just have a single total order, which is always used with that type in any
generic order-sensitive operation, including any ranges defined
Jeff Davis wrote:
On Sun, 2011-06-26 at 22:29 -0700, Darren Duncan wrote:
Tom Lane wrote:
Darren Duncan writes:
I believe that the best general solution here is for every ordered base type to
just have a single total order, which is always used with that type in any
generic order-sensitive
ld always be consistent on
transaction boundaries, at the very least, if not on statement boundaries.
As to whether B's failure happens when it tries to commit or happens earlier,
based on visibility issues with A's changes, doesn't matter to me so much (do
what works best for you/o
t;.
A Perl 6 analogy being something like:
$mytbl.map:{ .mycol + $myvar * $myparam }
aka:
$mytbl.map:{ $_.mycol + $myvar * $myparam }
--
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Pavel Stehule wrote:
2011/3/26 Darren Duncan :
I mention 2 possible solutions here, both which involve syntax alterations,
each between the -- lines. I personally like the second/lower
option more.
-1
this is not based on any pattern on SQL. It's not simple, and it
introd
r substituted for some parameter or there be other grief as I seem to
recall having in 8.4. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
replacement.
In any event, QUEL was somewhat similar to SQL.
-- Darren Duncan
Rajasekhar Yakkali wrote:
"Following a great deal of discussion, I'm pleased to announce that the
PostgreSQL Core team has decided that the major theme for the 9.1
release, due in 2011, will be 'NoSQL'.
foo can where the latter
is a case-insensitive identifier.
As for the SQL standard for bind parameters, as I recall they use :foo and so
:"foo" would be the sensitive more general case of that.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
Robert Haas wrote:
I am halfway tempted to say that we need to invent our own procedural
language that is designed not for compatibility with the SQL standard
or Oracle, but for non-crappiness.
I'm way ahead of you on that one. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (
g 8.4+ has named subqueries which handle a lot of cases
where temp tables would otherwise be used, I would certainly expect those to
work when you're dealing with a readonly database.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
Jeff Davis wrote:
On Thu, 2011-07-07 at 20:56 -0700, Darren Duncan wrote:
When you create a temporary table, PostgreSQL needs to add rows in
pg_class, pg_attribute, and probably other system catalogs. So there are
writes, which aren't possible in a read-only transaction. Hence the
error. A
1 - 100 of 162 matches
Mail list logo
