Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-21 Thread David Fetter
On Thu, Feb 18, 2010 at 01:51:08PM -0800, David Fetter wrote: > Folks, > > While hacking on PL/Parrot, I ran across an issue where when trying > to load PL/pgsql, it's done unconditionally and fails. How do we > fix pg_regress to be a little more subtle about this? For now, and for the archives,

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-21 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian writes: > > Tom Lane wrote: > >> Attached is a draft patch (no doc changes) that implements CREATE OR > >> REPLACE LANGUAGE > > > How is pg_migrator affected by this? It always loads the the dump as > > the super-user. How will the pg_dump use CREATE OR REPLACE L

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-21 Thread Tom Lane
Bruce Momjian writes: > Tom Lane wrote: >> Attached is a draft patch (no doc changes) that implements CREATE OR >> REPLACE LANGUAGE > How is pg_migrator affected by this? It always loads the the dump as > the super-user. How will the pg_dump use CREATE OR REPLACE LANGUAGE? pg_dump would issue

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-21 Thread Tom Lane
Robert Haas writes: > On Sun, Feb 21, 2010 at 1:21 PM, Tom Lane wrote: >> It will be owned by the bootstrap superuser, so the case is exactly >> the one that a non-superuser DBA would be faced with. > Or even a superuser other than the bootstrap superuser, no? I dump > out the DB on my 8.4 serv

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-21 Thread Bruce Momjian
Tom Lane wrote: > Robert Haas writes: > > On Feb 20, 2010, at 10:56 PM, Tom Lane wrote: > >> There is a very clear set of behaviors that CORL ought to have given > >> the precedents of our other COR commands. If we don't make it do > >> things that way then we are going to surprise users, and we

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-21 Thread Robert Haas
On Sun, Feb 21, 2010 at 1:21 PM, Tom Lane wrote: > Robert Haas writes: >> Well, I'm a big fan of CREATE OR REPLACE anything so I like the patch >> regardless of whether it solves the current problem, but having said >> that, I'm not clear on whether it does in fact solve the current >> problem.  

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-21 Thread Tom Lane
Robert Haas writes: > Well, I'm a big fan of CREATE OR REPLACE anything so I like the patch > regardless of whether it solves the current problem, but having said > that, I'm not clear on whether it does in fact solve the current > problem. When PL/pgsql is installed by default, is it going to en

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-21 Thread Robert Haas
On Sun, Feb 21, 2010 at 12:29 PM, Tom Lane wrote: > Robert Haas writes: >> On Feb 20, 2010, at 10:56 PM, Tom Lane wrote: >>> There is a very clear set of behaviors that CORL ought to have given >>> the precedents of our other COR commands.  If we don't make it do >>> things that way then we are

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-21 Thread Tom Lane
Robert Haas writes: > On Feb 20, 2010, at 10:56 PM, Tom Lane wrote: >> There is a very clear set of behaviors that CORL ought to have given >> the precedents of our other COR commands. If we don't make it do >> things that way then we are going to surprise users, and we are also >> going to pain

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-20 Thread Robert Haas
On Feb 20, 2010, at 10:56 PM, Tom Lane wrote: > Robert Haas writes: >> I think the most likely use of CREATE OR REPLACE [LANGUAGE] is to >> avoid >> an error when creating a language that might already exist. But it >> doesn't seem like the only possible use. Perhaps you've done an >> in-place

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-20 Thread Tom Lane
Robert Haas writes: > I think the most likely use of CREATE OR REPLACE [LANGUAGE] is to avoid > an error when creating a language that might already exist. But it > doesn't seem like the only possible use. Perhaps you've done an > in-place upgrade to version 9.0 and you'd like to add an inline >

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-20 Thread Robert Haas
On Sat, Feb 20, 2010 at 6:42 PM, David Christensen wrote: > In what cases would one be able to meaningfully REPLACE a language, other > than to not break when encountering an already installed language?  i.e., in > which cases would this not invalidate functions already written if you were > chang

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-20 Thread Bruce Momjian
Tom Lane wrote: > David Christensen writes: > > On Feb 20, 2010, at 5:16 PM, Bruce Momjian wrote: > >> If you implement #1, why would you have pg_dump issue CREATE OR > >> REPLACE LANGUAGE? We don't do the "OR REPLACE" part for any other > >> object I can think of, so why would pg_dump do it for

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-20 Thread Tom Lane
David Christensen writes: > On Feb 20, 2010, at 5:16 PM, Bruce Momjian wrote: >> If you implement #1, why would you have pg_dump issue CREATE OR >> REPLACE LANGUAGE? We don't do the "OR REPLACE" part for any other >> object I can think of, so why would pg_dump do it for languages by >> default?

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-20 Thread David E. Wheeler
On Feb 20, 2010, at 3:57 PM, Tom Lane wrote: >> And if so, would that be a syntax we'd want to accept in general? >> Could the be a CREATE IF NOT EXISTS TABLE? > > *Please* go read some of the linked older discussions before you propose > that. I don't want to rehash it yet again. :-) Was jus

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-20 Thread Tom Lane
"David E. Wheeler" writes: > Just throwing this out there: would a syntax such as CREATE OF NOT > EXISTS, a complement to DROP IF EXISTS, avoid the permissions issue? No, it'd just move it to a different place: now you risk breaking the restored state rather than pre-existing state. > And if

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-20 Thread David E. Wheeler
On Feb 20, 2010, at 15:18, Andrew Dunstan wrote: I also think we need to state explicitly that module authors can not expect build files to be version ignorant and always work. Even if we do something that handles this particular issue, that is likely to be a happy coincidence rather than

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-20 Thread David E. Wheeler
On Feb 20, 2010, at 15:03, Tom Lane wrote: Well, I'm willing to implement CREATE OR REPLACE LANGUAGE if people are agreed that that's a reasonable fix. I'm slightly worried about the restore-could-change-ownership issue, but I think that's much less likely to cause problems than embedding spec

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-20 Thread David Christensen
On Feb 20, 2010, at 5:16 PM, Bruce Momjian wrote: Robert Haas wrote: On Sat, Feb 20, 2010 at 5:53 PM, Tom Lane wrote: Robert Haas writes: On Sat, Feb 20, 2010 at 2:51 PM, Bruce Momjian wrote: Well, I was asking why you labeled it "must fix" rather than "should fix". ?I am fine with th

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-20 Thread Bruce Momjian
Tom Lane wrote: > Robert Haas writes: > > On Sat, Feb 20, 2010 at 5:53 PM, Tom Lane wrote: > >> I don't think that the way to fix this is to have an ugly kluge in > >> pg_dump and another ugly kluge in pg_regress (and no doubt ugly kluges > >> elsewhere by the time all the dust settles). > > > I

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-20 Thread Andrew Dunstan
Robert Haas wrote: IMO, the non-ugly kludges are (1) implement CREATE OR REPLACE LANGUAGE and (2) revert the original patch. Do you want to do one of those (which?) or do you have another idea? I thought we seemed to be converging on some agreement on CREATE OR REPLACE LANGUAGE. If

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-20 Thread Bruce Momjian
Robert Haas wrote: > On Sat, Feb 20, 2010 at 5:53 PM, Tom Lane wrote: > > Robert Haas writes: > >> On Sat, Feb 20, 2010 at 2:51 PM, Bruce Momjian wrote: > >>> Well, I was asking why you labeled it "must fix" rather than "should > >>> fix". ?I am fine with the pg_regress.c change. > > > >> Yeah,

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-20 Thread Tom Lane
Robert Haas writes: > On Sat, Feb 20, 2010 at 5:53 PM, Tom Lane wrote: >> I don't think that the way to fix this is to have an ugly kluge in >> pg_dump and another ugly kluge in pg_regress (and no doubt ugly kluges >> elsewhere by the time all the dust settles). > IMO, the non-ugly kludges are (

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-20 Thread Robert Haas
On Sat, Feb 20, 2010 at 5:53 PM, Tom Lane wrote: > Robert Haas writes: >> On Sat, Feb 20, 2010 at 2:51 PM, Bruce Momjian wrote: >>> Well, I was asking why you labeled it "must fix" rather than "should >>> fix".  I am fine with the pg_regress.c change. > >> Yeah, if it makes life easier for other

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-20 Thread Tom Lane
Robert Haas writes: > On Sat, Feb 20, 2010 at 2:51 PM, Bruce Momjian wrote: >> Well, I was asking why you labeled it "must fix" rather than "should >> fix".  I am fine with the pg_regress.c change. > Yeah, if it makes life easier for other people, I say we go for it. I don't think that the way

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-20 Thread Robert Haas
On Sat, Feb 20, 2010 at 2:51 PM, Bruce Momjian wrote: > David E. Wheeler wrote: >> On Feb 20, 2010, at 11:03 AM, Bruce Momjian wrote: >> >> >> There is also the "must fix" issue with pg_regress. >> > >> > Why?  My pg_regress runs just fine.  If you are talking about 3rd party >> > modules, I sugge

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-20 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian writes: > > Tom Lane wrote: > >> I would have said that some time ago, except that I think we have a > >> "must fix" issue here: isn't pg_upgrade broken for any database > >> containing plpgsql? A decent solution for that probably will allow > >> something to fall

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-20 Thread Tom Lane
Bruce Momjian writes: > Tom Lane wrote: >> I would have said that some time ago, except that I think we have a >> "must fix" issue here: isn't pg_upgrade broken for any database >> containing plpgsql? A decent solution for that probably will allow >> something to fall out for the regression test

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-20 Thread Bruce Momjian
David E. Wheeler wrote: > On Feb 20, 2010, at 11:03 AM, Bruce Momjian wrote: > > >> There is also the "must fix" issue with pg_regress. > > > > Why? My pg_regress runs just fine. If you are talking about 3rd party > > modules, I suggested conditional Makefile rules. > > Because you can either m

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-20 Thread David E. Wheeler
On Feb 20, 2010, at 11:03 AM, Bruce Momjian wrote: >> There is also the "must fix" issue with pg_regress. > > Why? My pg_regress runs just fine. If you are talking about 3rd party > modules, I suggested conditional Makefile rules. Because you can either make the simple change to pg_regress tha

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-20 Thread Bruce Momjian
David E. Wheeler wrote: > On Feb 20, 2010, at 9:49 AM, Tom Lane wrote: > > >> This discussion is sounding very design-ish, which makes me think we > >> should just leave things unchanged for 9.0 and have external regression > >> test designers work around this problem in their Makefiles, as Alvaro

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-20 Thread David E. Wheeler
On Feb 20, 2010, at 9:49 AM, Tom Lane wrote: >> This discussion is sounding very design-ish, which makes me think we >> should just leave things unchanged for 9.0 and have external regression >> test designers work around this problem in their Makefiles, as Alvaro >> suggested. > > I would have s

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-20 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian writes: > > This discussion is sounding very design-ish, which makes me think we > > should just leave things unchanged for 9.0 and have external regression > > test designers work around this problem in their Makefiles, as Alvaro > > suggested. > > I would have sa

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-20 Thread Tom Lane
Bruce Momjian writes: > This discussion is sounding very design-ish, which makes me think we > should just leave things unchanged for 9.0 and have external regression > test designers work around this problem in their Makefiles, as Alvaro > suggested. I would have said that some time ago, except

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-20 Thread Bruce Momjian
Dimitri Fontaine wrote: > Tom Lane writes: > > Well, that isn't really going to help us in terms of what to do for 9.0. > > But the possibility that something like this might happen in future is > > one thing that makes me hesitant about extending CREATE LANGUAGE right > > now --- the more bells a

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-19 Thread Dimitri Fontaine
Tom Lane writes: > Well, that isn't really going to help us in terms of what to do for 9.0. > But the possibility that something like this might happen in future is > one thing that makes me hesitant about extending CREATE LANGUAGE right > now --- the more bells and whistles we put on it, the hard

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-19 Thread Tom Lane
Robert Haas writes: > On Fri, Feb 19, 2010 at 2:09 PM, Tom Lane wrote: >> The sticking point for me is still whether or not it's really a good >> idea for pg_dump to be emitting CREATE OR REPLACE LANGUAGE.  It does not >> do that for any other object type.  On the other hand, we've already >> mad

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-19 Thread Robert Haas
On Fri, Feb 19, 2010 at 2:09 PM, Tom Lane wrote: > David Fetter writes: >> CREATE OR REPLACE LANGUAGE is an even bigger tar pit. >> http://archives.postgresql.org/pgsql-hackers/2009-10/msg00386.php > > The reason that patch got rejected was that it was implementing > CREATE IF NOT EXISTS --- unde

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-19 Thread Tom Lane
Dimitri Fontaine writes: > Not sure how helpful I'll be there, but I can't help placing the > extension's proposal again. > If we had extensions here, plpgsql would be a core maintained extension, > made available by CREATE EXTENSION in the database (which initdb would > do in templates), then ha

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-19 Thread Dimitri Fontaine
Tom Lane writes: > Robert Haas writes: >> I am still of the opinion that changing this was a bad idea for >> exactly this reason. We could perhaps ameliorate this problem by >> implementing CREATE OR REPLACE for languages and emitting that >> instead; then the command in the dump would be a noop

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-19 Thread Tom Lane
David Fetter writes: > CREATE OR REPLACE LANGUAGE is an even bigger tar pit. > http://archives.postgresql.org/pgsql-hackers/2009-10/msg00386.php The reason that patch got rejected was that it was implementing CREATE IF NOT EXISTS --- under a false name. The problem with that is summarized here:

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-19 Thread Robert Haas
On Fri, Feb 19, 2010 at 1:44 PM, Tom Lane wrote: > Did we have consensus on exactly what CREATE OR REPLACE LANGUAGE would > do?  Particularly in cases where the existing definition doesn't match > pg_pltemplate? I am of the opinion that any CREATE OR REPLACE command that completes without error s

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-19 Thread Tom Lane
Robert Haas writes: > On Thu, Feb 18, 2010 at 11:38 PM, Tom Lane wrote: >> ... Let me point out that >> choosing to install plpgsql by default has already broken "--single" >> restore of practically every pg_dump out there.  Nobody batted an eye >> about that.  Why are we suddenly so concerned ab

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-19 Thread David Fetter
On Fri, Feb 19, 2010 at 01:34:46PM -0500, Robert Haas wrote: > On Thu, Feb 18, 2010 at 11:38 PM, Tom Lane wrote: > > Takahiro Itagaki writes: > >> David Fetter wrote: > >>> support both pre-9.0 and post-9.0 PostgreSQLs.  David Wheeler has > >>> suggested that we special-case PL/pgsql for 9.0 and

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-19 Thread Robert Haas
On Thu, Feb 18, 2010 at 11:38 PM, Tom Lane wrote: > Takahiro Itagaki writes: >> David Fetter wrote: >>> support both pre-9.0 and post-9.0 PostgreSQLs.  David Wheeler has >>> suggested that we special-case PL/pgsql for 9.0 and greater, as it's >>> in template0, where those tests are based. > >> +

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-19 Thread David E . Wheeler
On Feb 19, 2010, at 7:43 AM, David E. Wheeler wrote: > Usually PGXS loads after setting all the environment variables, though I > suspect that it wouldn't have any side effects to set regress_opts afterward. > Also, there is no MAJORVERSION in earlier versions, so module authors would > have to

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-19 Thread David E. Wheeler
On Feb 19, 2010, at 5:36 AM, Alvaro Herrera wrote: >> Because it's a lot easier for `pg_regress --load-language=plpgsql` to mean >> "ensure the language is installed" than it is for 3rd-party test suites to >> detect what version they're being installed against. > > Why doesn't the Makefile run

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-19 Thread Alvaro Herrera
David E. Wheeler wrote: > On Feb 18, 2010, at 8:38 PM, Tom Lane wrote: > > >> The regression test in the core is targeting only its version, > >> but some external projects have version-independent tests. > > > > I think it's more like "are under the fond illusion that their tests are > > version

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-19 Thread Magnus Hagander
2010/2/19 Tom Lane : > Takahiro Itagaki writes: >> David Fetter wrote: >>> support both pre-9.0 and post-9.0 PostgreSQLs.  David Wheeler has >>> suggested that we special-case PL/pgsql for 9.0 and greater, as it's >>> in template0, where those tests are based. > >> +1 for the CREATE LANGUAGE IF N

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-18 Thread David E. Wheeler
On Feb 18, 2010, at 8:38 PM, Tom Lane wrote: >> The regression test in the core is targeting only its version, >> but some external projects have version-independent tests. > > I think it's more like "are under the fond illusion that their tests are > version-independent". Are we going to back o

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-18 Thread Tom Lane
Takahiro Itagaki writes: > David Fetter wrote: >> support both pre-9.0 and post-9.0 PostgreSQLs. David Wheeler has >> suggested that we special-case PL/pgsql for 9.0 and greater, as it's >> in template0, where those tests are based. > +1 for the CREATE LANGUAGE IF NOT EXISTS behavior. > The re

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-18 Thread Takahiro Itagaki
David Fetter wrote: > Any external projects will fail on this if they're attempting to > support both pre-9.0 and post-9.0 PostgreSQLs. David Wheeler has > suggested that we special-case PL/pgsql for 9.0 and greater, as it's > in template0, where those tests are based. +1 for the CREATE LANGUA

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-18 Thread David Fetter
On Fri, Feb 19, 2010 at 12:26:29AM -0200, Euler Taveira de Oliveira wrote: > David Fetter escreveu: > > OK, I know it's late, but having PL/pgsql on by default has caused > > an unforeseen need: --require-language. > > > Why? IMHO pg_regress should be used with the same postgres version > it was b

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-18 Thread Euler Taveira de Oliveira
David Fetter escreveu: > OK, I know it's late, but having PL/pgsql on by default has caused an > unforeseen need: --require-language. > Why? IMHO pg_regress should be used with the same postgres version it was built with. So any tests that use --load-language=plpgsql should be fixed. Besides we co

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-18 Thread David Fetter
On Thu, Feb 18, 2010 at 06:27:30PM -0500, Tom Lane wrote: > David Fetter writes: > > While hacking on PL/Parrot, I ran across an issue where when > > trying to load PL/pgsql, it's done unconditionally and fails. How > > do we fix pg_regress to be a little more subtle about this? > > Why exactly

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-18 Thread David E. Wheeler
On Feb 18, 2010, at 3:27 PM, Tom Lane wrote: >> While hacking on PL/Parrot, I ran across an issue where when trying to >> load PL/pgsql, it's done unconditionally and fails. How do we fix >> pg_regress to be a little more subtle about this? > > Why exactly would we want it to not fail? Regressi

Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-18 Thread Tom Lane
David Fetter writes: > While hacking on PL/Parrot, I ran across an issue where when trying to > load PL/pgsql, it's done unconditionally and fails. How do we fix > pg_regress to be a little more subtle about this? Why exactly would we want it to not fail? Regression tests are not about papering

[HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

2010-02-18 Thread David Fetter
Folks, While hacking on PL/Parrot, I ran across an issue where when trying to load PL/pgsql, it's done unconditionally and fails. How do we fix pg_regress to be a little more subtle about this? Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: d